Endpoint Protection

We have SEP running now the last month or so and all is fine. We have our major sites covered.
We are planning to roll out SEP V11 to many laptops around our region that would be located in smaller sites.

These laptops would be pretty much stand alone as they will not be in an office that has a WAN connection to our SEPM via a VPN or any other network connection to our WAN. They will not be remotely connecting into our network environment at any time unless 1) they travel to one of our offices 2) VPN tokens are distributed to them in the future.

Now we are planning to give these users a CD with a Managed Setup.exe because we feel it will give us the advantage of future manageability.
For example if a user comes into our office in 6 months time with this managed client it should "check into" our SEPM and give us details about infections etc. Am I right here?

However my concern is the download of updates. Will the SEP client update away on schedule even though it cannot ever connect to the SEPM. I know this will mean having all the policies set before hand before you create the installation package. I am just wondering if there are any un foreseen issues here.

Are we better of shipping an unmanaged client?

No I think you are doing the right thing shipping as managed clients. I guess it does depend on exactly how long these clients are "out" of the office for. If you are pushing 6 months + I could see possible issues of upgrading clients to newer and better versions. Any sorts of policy changes during this time too will not get applied to the managed clients because they can't connect to the SEPM. Also clients that don't connect to the SEPM within 30 days will by default get deleted from the SEPM database. This is fixable if you want to go down that route. Here is the steps to do this:

1. Open SEPM and click on the Admin tab.
2. Click on Servers.
3. Select the "Local Site" from the list of Servers.
4. Under "Tasks," select Edit Site Properties.
5. Under the "General" tab, there is a check box that says "Delete clients that have not connected for X days." By default this is set to 30. Change the    number of days as desired.
6. Click OK.

One thing you don't have to worry about is your clients getting definitions. By default they failover to the live update server if they can't get their definitions from the SEPM. So I guess my final answer for your question is it depends on how long they will actually be out of the office. Hopefully this information helps. Sorry I can't be of more help but it really depends on your specific situation.

Cheers
Grant

Cheers for that. I suppose we will go for the managed client but will need to be very careful on how the package will be created as we will have to give the end user a lot more freedom to change stuff as we will not be able to change things for them afterwards

As long as you have a way to connect to the internet then SEPM client would pull new virus updates frome thier... thanks...

By the way is this action made by default or do i have to configure this first..

thanks..

Managed clients are the way to go so you can control the various policies.

Edit your Live Update policy for the group in quesiton and ensure that both "Use Default Management Server" and "Use Live Update Server / Use Default Symantec Live Update Server" options are checked.  Note that by doing this, clients in this group will try to pull updates from both Managment and Symantec Live Update Servers even if they are on the WAN/LAN. 

It would be better to create a location based policy that checks if it can connect to a Management Server and if not, *then* get the updates from the Symantec Live Update Servers.

Grant, even if the clients were deleted by pruning, wouldn't they re-appear in the SEPM console once they connect to the WAN/LAN upon the next heartbeat?

Actually I don't know Rick. I can't find any document supporting this, but if that has been your experience I am not doubting you. It actually makes sense that it would link up again at the next heartbeat. However if you know that the clients are going to absent fromt he manager for more than 30 days then there is not reason not to extend that time period. That is why we give the option to extend it beyond 30 days. Good point though and I will look again for exactly where it says this.

Grant-

I've experienced a client that fell off came back on the console as it was turned off for weeks (past the age I set to remove clients).  I've also deleted clients from the console to have them re-appear on the next heartbeat (troubleshooting another problem).  I would really be curious to know if it goes beyond the pruning age set, if it was by design to come back to life and appear in the console.  It really makes sense as the sylink.xml file contains the key that tells the client who to communicate with.  If you find anything, please post.

Regarding the Liveupdate download u can allow the users to manually download the liveupdate. U can configure this according to the group which clients belong to as Liveupdate settinfgs policy in advance setings

Having forgot about this. Doing some testing tonight in a virtual machine I got all set up. My clients should be booted by tomorrow when I will re-introduce them back onto the LAN and see what happens. Will post my results.

Cheers
Grant-

Set the policies accordingly and apply to the groups reletaed to clients.

I think we should use Location Awareness for the Liveupdate.

Can we set the pruning age set per group? or the pruning be different in different groups?

Paul, the pruning options are set per site under Admin / Server / Edit Site Properties / General / Delete clients that have not connected for XX days

You can ship out a managed client under an individual group and you can config different LU policy for it. (Let these client download LU content from Symantec LU server not SEPM)
It is better to let these clients managed than unmanaged. 

Ok after doing my one small test, my clients where successfully purged from the client list. When I reintroduced them to the lan they were not "found" again. However I saw your post in the other thread on this similar issue, and your right successfully purging the clients has been a "hit or miss" issue for Symantec. The latest I have on the issue is that it is still being investigated. Take from that what you will, but it seems to be somewhat of an ongoing issue. It also doesn't appear to be pinned down to just one version. I will try to keep  you guys updated, but this is the latest I have. If you end up doing more testing you should let me know if you can. Hope all is well.

Grant-

Hi Grant,

Thanks for following up.  That's interesting to note your client did not re-appear in the SEPM.  What was your number of days to purge client set at?  How long after the clients were purged did you try to bring them online? 

Were you in push or pull mode and if pull, what's the heartbeat?  How long were your clients back online before you checked the SEPM if they connected? (Do you want to hire me for tech support? :-P LOL)

I'm asking so many questions as my real world example was offline past the number of days to purge and when brought back online, they re-appeard in the clients tab.  I don't remember what version of SEP/SEPM was at the time.  I could run an experiment but would like to address the problem of deleting purged/pruned clients from SEPM that still appear as failing defs/signatures first.  I know for a fact that deleting the client from SEPM will re-appear as a client on the next heartbeat with the same errors.

Although I would rather not, do you think it would be worth it to Symantec to report my findings by opening a support case (even after deleting the embedded database and re-installing in the past)?  I really don't want to uninstall/re-install SEPM and really don't want to blow away my embedded database, but if absolutely needed to problem solve, I would "take one for the team."

Yes sorry I should be more specific, in fact I should be specific as possible to help nail down some of the discrepancies surrounding this issue. So my setup is this.

a. Running both the server (Windows Server 2003 Standard Edition fully updated) and the client (Winows XP Professional fully updated) in vmware ver 1.0.9.
b. I set the Remove Client from database after X days option to 1 when I did this test. I waited an extra 12 hours after the 1 day to make sure the client would be successfully purged.
c. I then reintroduced the client to the network
d. I have them set up to pull definitions every hour, so after I reintroduced the client I waited an extra two hours to make positive I got a heartbeat in there where the SEPM could "find" the client on the heartbeat.

To answer you other questions I don't think you should have to be the one to take the bullet and test this out. Hey that is what I am here for right? So if you want to give me a specific setup ie) windows server 2003 with SAV 10 then I can test it out. I have access to all of the Symantec products plus any Microsoft OS. So whatever you need just tell me and I will run some test. Honestly you can open a case if you want, but it seems like they have quite a few open "investigating" as we speak so it might not do too much good. Also this issue happened mainly with SAV from what I see, but there are also reports of it happening in almost every version of SEP too so who knows? Let me know what you think as well as any settings you might want me to change for my next run at this.

Grant-

PS
If it were up to me I would hire you tomorrow to help with tech support lol. Hopefully you are getting enough rewards points to at least get a cool iPod or a trip to Hawaii or something.

Thanks for your help here

One last thing. Is it possible to send email alerts to an email address even though the client will have no ongoing communication to the SEPM.

I dont think its possible but just want to make sure.

No I don't think this is possible, at least not until those clients become back in contact with the SEPM. I say this because in order to use email alerts you need to first configure the SEPM to use your mail server. Then your SEPM contacts the mail server to send out the email when some alerts happens. Now since you arn't contacting the SEPM I don't see how this would work.

Hope this all helps
Grant-

Yep, what I thought it would do!
Thanks,

I'm going to take you up on this testing, but I'll post the info in this thread (sorry for hijacking this thread): https://www-secure.symantec.com/connect/forums/remove-decommissioned-computers-lists