> For the complete documentation index, see [llms.txt](https://docs.adaptiva.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adaptiva.com/platform/user-guide/locations/location-best-practices.md).

# Locations best practices

Best practices for creating and organizing Locations.

Locations define how content is shared across your network. If your locations do not accurately reflect your network, it can cause unnecessary strain on the network and slow content delivery.

Following these best practices will help you to create locations that are optimized for your network.

## Network topology considerations

Consider your physical network structure when planning your office locations. Think about how content flows from the central office to your devices across your network, and design your office Locations to reflect that topology.

* Plan for worst case scenarios to ensure that your network topology can handle the distribution of large content patches across all of your devices. For example, consider how a major Windows OS update will rollout across your network to every device.
* Make sure your locations do not cross physical network boundaries. This can lead to using the wrong transport protocol to share content, which can cause network inefficiency and potentially saturate the WAN link.
* Make sure that child offices are connected or routed in a physical network to their parent.
* When a subnet has mixed device connectivity (wired, WiFi, etc.) or any devices that do not support network broadcasts, such as Azure Cloud Services, configure the office as **WiFi**. This ensures that devices will communicate via unicast instead of broadcast.
* Minimize the number of Locations between child offices and the closest Location with internet access to the CDNs, as new content needs to be distributed down the parent chain before it reaches the child location. This can cause very large downloads to take longer to reach devices, and may cause them to miss their maintenance window, especially if content pre-staging is not enabled.
* Each parent office should have enough devices to support delivering content to all child offices. The following ratios are rough guidelines to ensure efficient content sharing from a parent office to its child offices:

  * Each server can efficiently handle at least 25 child offices.
  * Each workstation can efficiently handle at least 10 child offices.

  If a child office is configured as VPN, each client downloads directly from the parent office. **Consider each client in the VPN office as a separate child office when calculating ratios.**

  Depending on your network connections, devices may be able to support substantially more child offices.

## WiFi offices

The following best practices apply when you have a WiFi office that uses a subnet larger than a /24 network.

* WiFi [Locations](/platform/user-guide/locations.md) should not include subnets larger than /24 (256 IP addresses). If your WiFi subnet is greater than /24, create a Location for each logical /24 range in your subnet.

  For example, if you have a /23 WiFi subnet from 192.168.160.0 to 192.168.161.254, create a separate Location for each /24 range:

  * 192.168.160.0 to 192.168.160.254
  * 192.168.161.0 to 192.168.161.254

  In addition, each of these offices should enable the **Send Office Range** toggle. This toggle causes clients to ignore messages from clients outside their /24 range and helps to prevent network instability.
* Only enable the **Send Office Range** toggle when you are breaking a large subnet into smaller /24 ranges.
* Read [ARP Behavior in Wi-Fi offices](https://support.adaptiva.com/hc/en-us/articles/207988203-Issue-with-WiFi-Protocol-Client-version-5-5?brand_id=420704) on the Adaptiva Support Portal for more information on why subnets larger than a /24 network can cause network instability.

## Downloading content from the internet

Follow these best practices to ensure that devices can obtain and distribute content from the major internet CDNs.

* In cases where content sharing from a parent to a child office might be inefficient and the child office has a direct internet breakout (not through a data center location proxy), you can enable **Allow Direct CDN Download** on the child office to allow it to directly download the content from the CDN via the internet.
* Make sure every device in the Central Office or a location with **Allow Direct CDN Download** enabled has internet access to URLs listed in [Internet URLs - Clients](https://github.com/AdaptivaDocs/docs/tree/main/platform/site-planning/onesite-platform-planning.md#clients) so that they can download updates directly from the internet.
* Make sure that every device in a non-VPN Location can communicate and share content with every other device in the same Location. This is essential for peer-to-peer sharing to work properly.

## SaaS server and On-Premises Client Detection

The following best practices apply only to SaaS server setups:

* Without On-Premises Client Detection enabled, every unique public IP will be treated as a hidden **WiFi** office. This is because the SaaS server only sees the public IP address of any connected devices and has no visibility into the subnets of your physical networks.

  For small and mid-sized organizations, the default behavior (a single location per public IP) is usually sufficient, especially if there are under 254 devices on the physical network.

  If you need to create locations based on physical subnets, you must enable On-Premises Client Detection. This lets the SaaS server communicate with a device inside your network to obtain details about the internal network addresses.
* When configuring On-Premises Client Detection, specify a domain controller as a DNS target if possible, since domain controllers are more likely to be online and accessible at any given time.
* If you enable On-Premises Client Detection, add at least three devices to the central office, and ensure that all devices added to the central office have internet access to URLs listed in [Internet URLs - Clients](https://github.com/AdaptivaDocs/docs/tree/main/platform/site-planning/onesite-platform-planning.md#clients) so that they can download updates directly from the internet.

## Auto office creation settings

The following best practices apply to the Auto Location Creation setting:

* In a SaaS environment, if you want to enable Auto Location Creation, enable and configure On-Premises Client Detection first. Auto Location Creation is enabled by default in On-Premises environments.
* By default, Auto Locations are created as children of the Central office, using the location type of **Default**. We recommend that you change the location type to **WiFi** to ensure that all devices are captured correctly.
* If you expect a large number of auto created locations (for example, remote work environment), make sure that you specify a parent location that can support content distribution efficiently.
* Use Auto Location Creation to quickly identify changes to your network, such as a new subnet being added that you weren't aware of.
* In an on-premises environment, you can use the **Show No Office Clients** to troubleshoot why a device might not be getting content due to not getting properly assigned to an office. In SaaS environments, this option is less useful, since internet client offices are destroyed when the client shuts down, and those clients will be displayed in the list.