As part of on-going internal infrastructure projects, we have recently implemented new Endpoint security across our network namely Microsoft Forefront 2010. As part of the prerequisites for Forefront we needed to install Microsoft SCCM 2007.

The configuration of SCCM and Forefront generally went through without any issues, if not a lengthy process! Forefront automatically creates the client installation package and policy packages, which are used to apply settings to the client such as Anti-Virus scan schedules, Windows Firewall settings etc. So once SCCM is configured, the process of installing Forefront Endpoint security on top of SCCM is a fairly automated process in terms of configuration.

So far so good, SCCM fully configured and the Forefront client and policy packages ready to be pushed out to clients. I first of all choose to push out the Forefront client and policies to a client machine which was directly on our office network. This machine was added to a collection within SCCM where the Forefront client package was advertised to. The advertisement for the package was set to ‘Always rerun program’ so that there was no need to manually send out the advertisement to the client machine, this will automatically be sent out every time a new client is added to the related collection.

Clients directly inside the network could receive the package ok, but we also wanted packages to be sent out to clients which were connected via VPN and this is where the problem happened! The advertisement would make an attempt to be sent out to the client and the package would not arrive at the client machine, whilst connected via VPN.

So this made me question what was different been the clients directly on the network and those which were connected via VPN. One of the main differences in our case is that VPN clients are issued with a DHCP assigned IP address via our Cisco ASA Firewall. These addresses are in a different IP subnet than our internal office network, where our domain controllers and SCCM server sit. However, VPN clients still point to the same domain, domain controllers and DNS servers as clients in the internal office network.

There is a configuration setting within SCCM which allows you to specify what network or domain criteria clients need to match in order to connect to SCCM, known as ‘Boundaries’. To get to this within the Configuration Manager Console, expand Site Database, Site Management, SCCM Site Name, Site Settings and Boundaries.

There was already a boundary configured for clients which are a part of the domain where the local domain controllers are within a specific active directory site. However, this only covered clients which were within the same IP subnet as the active directory site.

Therefore I created another boundary as an IP address range rather than another active directory site. To do this I needed to be within the ‘Boundaries’ configuration as above, selected ‘New Boundary’ at the right hand side under actions, provided a description, selected our site code (in our case we only have the one SCCM site), selected the type as ‘IP address range’ and then entered the IP range which our Cisco ASA serves out to VPN clients.

Also another important setting in this configuration especially for VPN clients which will be connecting in through varying bandwidth speeds is to set the network connection type as ‘slow or unreliable’.

After this new boundary was created, I was then able to push out the Forefront client and indeed any other software packages to clients connected via VPN.

Our SCCM setup is a single server environment but it is possible to scale this out over several site servers. This would be particularly useful if you have a larger enterprise and therefore even the load out over several SCCM site servers or your domain is based over several physical sites/offices. Placing a SCCM site server at each physical location would mean that SCCM packages could be pushed out via the local site network, rather than using network links from the primary SCCM site location to secondary sites. If you were to go with the option of scaling out SCCM, you may find that you also need to create further boundaries for those clients at different physical sites/offices, dependent on what IP subnet they are within.

Back to blog