SEP - GUP Behavior

[Migration User]

I have a GUP assigned to a group. The group has computers from 2 different subnets. Subnet 1 has a GUP. Subnet 2 does not have a GUP. I installed the SEP client to Subnet 2 computers last night around 23:30. Subnet 1's definitions are currently up to date however, Subnet 2 (the subnet without the GUP) is still stuck with old definition files. From what I've read, the clients in Subnet 2 should default to the SEPM server providing these computers content since there is no GUP on the local subnet. Is my perception of GUP operation correct? If it is, what could be preventing the Subnet 2 clients from being updated?

Thanks in advance. 

[Migration User]

How do you defined the GUP .As far as I know if you are select  use single group update provider option in the LU policy clients will receive updates from the GUP which is specified for that group irrespective of subnet.If you select multiple group update provider option clients will receive updates from the GUP which is present in the same subnet only.If a client is not able to reach its GUP it will sit quiet until the specified time for bypassing GUP in the LU policy(It will not receive updates from SEPM until that time reaches.if you specified never,clients will never receive updates from SEPM directly.)....I think in your case if you used multiple GUP option there is one more option as use this GUP if there is no GUP in that specific subnet.(I am not able to recollect the exact words ,but it means like this.)

[Migration User]

Assure that  all your clients are able to reach the GUP in 2967 port.....

[postechgeek]

You said that both PCs from the two subnets are in the same group. If you assigned a GUP to that group, all the clients might be trying to content from the GUP. Do the PCs in two subnets have access to each other? Firewall restrictions are something. What subnet is the GUP on?

You might want to create a new group without a GUP setup and move the computers from subnet 2 to that group, and see if they update. Just an idea.

Mike

[Migration User]

Ok, I think I found the explanation I needed, it just took longer. I will also have to rethink my Groupings.

1. GUPs can only service their local subnets when using the "Multiple Group Update Providers" option (exception: see rule 3).
2. GUPs can only service machines in their group.
3. In the event a GUP in a group cannot reach the rest of it's local subnet to service, or the computers in that subnet cannot reach the GUP, you can specify a fall back server outside of that subnet to rely on for updates. The caveat is that the fall back GUP has to be in the same group, I think (untested).

Essentially, a GUP is designed to offload bandwidth. Spanning subnets would defeat this purpose. For example, a client (192.168.0.2/24) reaching out to a GUP (192.168.1.2/24), would essentially be spanning the 2 subnets for updates.

So in my specific example, 192.168.0.0 represents a subnet at the far end of a slow WAN link. Subnet 192.168.0.0 is located in New York City and 192.168.1.0 is located in Denver while the SEPM is located in Atlanta. New York has a GUP but Denver does not. The clients in Denver want to associate with a GUP in the 192.168.1.0 subnet, but there isn't any. Since there is a GUP assigned to that group (because NYC and Denver fall into the same client group on the SEPM) Denver would want to associate with NYC's GUP if spanning subnets was an option. This would not be optimal. The slow WAN link from Atlanta to NYC would essentially be flooded. While the GUP in NYC would service all of the 192.168.0.0 network it would also want to service the 192.168.1.0 network if spanning subnets was allowed. This would eventually mean that the WAN link from Atlanta to NYC would be doing double the work which completely defeats the purpose of the GUP.

If you look under your LiveUpdate policy where your GUPs are defined (Server Settings > Group Update Provider > Multiple Group Update Providers then select "Configure Group Update Provider List") you will notice there is a section at the bottom of the rules list that allows you to "Specify the host name or IP address of a Group Update Provider on a different subnet to be used, if Group Update Providers on the Local subnet are unavailable." I am going to try this option with the SEPM server first but I am not sure it will work as the SEPM server itself, is in a different Client Group. 

My biggest issue with this is that I was using documentation from RU4. The administration guide for RU6 has much more information in it about GUPs.

[Migration User]

Hi.

We've also run into the problem of what a GUP thinks is a subnet & how clients are not aware of the neasrest GUP.

 

Our SEP engineers & Tech document 94265 mention Location awareness, but don't explain how this is supposed to work. After some digging, I've come up with the solution described further down. A brief description of our environment is at the bottom.

 

Solution

This applies to generic workstations only, servers & task specific workstations are in a seperate SEP group defined under My Company. 

 

All generic workstations are in one Group.

 

On the Policies tab, create the required amount of Live Update policies. This number should be equal to the amount of GUPs you have and equal to the amount of locations you will create. AV, Firewall, Intrusion Prevention & Centralized Exceptions policy are common across all workstations. We'll only use one shared policy for the other technologies.

• Conditions for LiveUpdate policy
• Specify Internal / External LiveUpdate Server as per Company policy.
• Specify single GUP (Not a GUP list)
• Specify TCP port, content cache & maximum bandwidth as per your company standard.
• Copy the policy so that you don't have to redefine the settings again & again.

 

On the client tab with the workstation group selected, add the same amount of locations as your GUPs & Policies above. Every location will use a shared AV, Firewall, Intrusion Prevention & Centralized Exceptions policy. Every location will use its own corresponding LiveUpdate policy as defined in the previous paragraph.

• Conditions for Location
• What makes this location unique?
• We'll use Default gateways for each subnet.
• Multiple gateways can be used per location.
• As the default gateway defines the network, we can group multiple networks into one location
• This allows use to use one geographical GUP for several logical networks that are physically close together.

 

Screenshot of several locations using shared AV, FW, IPS, Exceptions policy, but their own unique LiveUpdate policy. All of these locations apply to the one Group for generic workstations.

 

 

Environment

• World wide operation
• 2x DHCP servers
• 2x DNS servers
• 900x IP subnets
• subnets as small a 5 hosts
• ±140 AD Sites
• Fairly flat AD OU structure, not based on location.
• Centrally managed operating environment using SEP, Altiris & AD.

 

I hope this helps somebody else out there with GUP & locations & the subnet problems discovered so far. If you have any comments, please reply. We are not going to entertain the thought of 1000's of GUPs

[Migration User]

A SEP client can get updates from a GUP regardless of whether it is located in its own group or not.
In older versions of SEP it did matter but that was back in MR1/2/3 etc.

If you have a site with multiple routed subnets the easiest way to approach it is to create a group on the SEPM with a single GUP assigned. Then use the moveclients script on the server to ensure all SEP clients are moved into this group based on IP address range.

You could also consider using a central LiveUpdate Administration server that replicates to remote LUA repositories on UNC/FTP/HTTP servers at each local site.

Then you can either use groups or if you are lucky enough to have dns servers at each site you can do some simple dns poisining to ensure SEP clients get updates from their local LUA source

[Migration User]

It is not recommended to use more than 7 locations for the following reasons:

• SEPM has to keep track of up to 7 policies for each locations as they are unique. This quickly gets into really high numbers if you are AD syncing your groups, even if they don't have clients SEPM is keeping track of the locations and each policy etc.
• SEP clients have to check their location every X amount of seconds
• Ease of administration

The simplest solution in your situation is to probably do the following:

• create a group just for servers as they are turned on 24x7 and can get updates from the SEPM easily
• create one group per remote site
• Assign a single local GUP to each group for the remote sites
• Identify the IP address ranges of each remote site
• Use the moveclients utility inculded in the SEP media to move clients into the correct groups based on their IP address. This can be run every 5 minutes and runs very quickly.

Alternatively you could use a central LiveUpdate Administration server to download updates and distribute them to a server at each remote site. LUA can do this or you can use something like DFS. The repositories can be UNC/FTP/HTTP. You then just need a LU policy on each group that points clients to their local LUA source.

Unfortunately there is just not easy way to approach the design when there are lots of remote sites with multiple routed subnets. The next release does have some major improvements around this though...

[Migration User]

Hi.

We are not syncing AD. Besides, our AD OUs don't reflect our geographical locations anyway.

You talk about 'up to 7 policies for each location as they are unique'. Isn't that what shared policies are for. So that they are NOT unique.

 

With multiple locations I only have to update the LiveUpdate policy & location definition inside the SEPM console. If I use Groups, the moveclients script has to run regularly. It relies on an external text file that can get lost / corrupt & only resides on one box. With our two SEPM servers, everything inside the console is automatically part of the environment & happens / is configured on both servers. In this setup, losing one server is not a train smash. Losing the server that has the script & text file is not going to be fun.

 

Using LUA might be an option, but then again, it's settings & definitions outside of SEPM.

 

About those 'major improvements in the next version', where are they recorded? Got a link? Don't want to rely on vaporware. With a standard operating environment, getting updates packaged & the paperwork signed off can be a major schlepp in some companies.

[Migration User]

The policies are unique to that location and have to be stored etc.

There is a reason Symantec only recommend 7 locations. Trust me :)

I do have a client at the moment where they have 35+ locations but they only have 5-6000 SEP clients and it does appear to be working for them. No idea when it will stop scaling though.

There is no reason you can't run the scripts on both SEPM's. It is essentially just trawling through the database and moving clients based on the variables you give it. It runs very quickly and you can schedule it every 5-10 minutes if you like.

Also no reason you couldn't make the text file with IP's read only as well.

There is no record of the new features of SEP as they are not finalised and the new version hasn't been released into even beta testing yet as far as I am aware. I think more details will emerge early next year