Hi,
Please find the answers below.
1. Looks like I need to set up a gpo for our mostly 64 bit clients and also one for 32 bit. I did not try it but I don't know how well it would play with one gpo having both SEP client installs, as one or the other would fail and that might create havoc everytime it starts up. I use Hyena so seperating by OS is pretty easy. Mostly curious. I used to use a startup script that would check for processor type etc. but it is a pain to setup and trouble shoot with each version.
- Concern is to distribute 32bit and 64bit package to the same OU/group.And we want to deploy it using GPO and startup script.
A-> Easiest way I think is you would need to create a sub group/OU to diffrentiate between 64bit and 32bit.As it is a sub OU it would inherit all the policies assigned you just need to add the startupscript which would point to 64 bit or 32 bit based on the group.
2. When I followed the guide it said to take the install files and do an administrative install by going \\sharename -a etc. When I did that and deployed by GPO the SEP client installed but when I kicked up the screen on the client it didn't even have antivirus protection and just had the SEP screen and Client logs nothing else. Did I do something wrong? So instead I exported the client out of the console and copied that to my shared folder for the gpo to use. That worked fine but again curious on that.
- You would need to export the install files from SEPM so that clients would communicate to the respective groups. not sure what went wrong during administrative install .
3. As we know in the client install settings we can do no user interaction and I think it can reboot the computer etc. Is that what I want if I am deploying by GPO to not have any user interaction etc. since it is doing it on startup? I have called it forced install on my client settings.
- I would recommend you to have delayed restart as an option as sometimes SEP installtion would take some time - user might be on some important work and it would restart automatically . Users dont like it.
4. As per my other post the GUP works great so far.
- GUP is an awesome feature to save bandwidth and can be used in an efficient way. Just need to know some basics of it.
https://www-secure.symantec.com/connect/articles/configuring-group-update-providers-symantec-endpoint-protection-110-ru5
http://www.symantec.com/business/support/index?page=content&id=TECH93813
5. I have heard of an issue where if a user is logged into the computer that it will do its updates from the Symantec web site instead of locally or the GUP. Seems like a registry entry has to be changed, something like the following:
- This depends on the liveupdate policy you have configured for the specific groups. You can configure clients in such a way that it would not go out on internet to get the updates, it would take updates only from GUP, it would take updates from GUP and SEPM.
You just need to explore the liveupdate policy to understand how it works.
The registry key which you gave are reference with the proxy settings. When troubleshooting on Liveupdate sometimes we would need to delete these registries so system account flushes the old Proxy settings it has saved. Resetting is not at all pain. Just delete couple of registries and it will be reset on next restart of the system.