Endpoint Protection

I am running SEPM 11.0 RU 5 and clients being deployed are 11.0 RU 5.  Here's the issue.

We are using SCCM for the deployment.  We are doing this for a couple reasons.  Mainly so we can attach extra commands during the distribution, like making sure certain Outlook reg keys are not present, and stopping the LiceUpdate process before install.  Anyway, I'll end up having about 90+ient groups.  About 30 because of all the remote facilities we have, and each of them will have their own LiveUpdate policy.  Within each remote location, there are workstations, standard servers and SQL servers.  So three groups for each remote location.  I do not have to have 90+ exported packages.

What I would like to do is have the Server 32bit, Server 64bit, Workstation 32bit and Workstation 64bit packages and just figure out the best way to route them to the correct group.  I have all the exported sylink.xml files.  We tried using WISE script and after sending the install files out to a client, BUT before the install we copied out a specified sylink.xml file to the install directory, but SCCM did not ike this and came up with the error "Content Mismatch".  Basically it would not install because the data it had sent to the client was now different.

Is there any MSI scripting or anything that will allow you to specify a certain sylink.xml file to use?

I know I can manually move these clients, but many of the deployments will be occurring late at night and if the client is not in the right group and doesn't have the correct exclusions, I would be afraid of a SQL box running the virus scan immediately after install and not knowing to exclude the SQL database files, thus potentially corrupting the data.

Sorry if this is confusing, but I will be more than happy to clarify if you have specific questions.

 You can export a package non-single exe package then in that package replace the sylink file for the group you want to do installation.

After you have finished deployment for that group do the deployment for others groups by replacing the sylink in the package.

I highly recommend you get rid of all of your groups and simplify as much as possible.
You shouldnt need a liveupdate policy for each location if you use GUP wildcard rules based on hostname.
In my experience it is highly desirable to keep the number of groups down to a minimum.

If you really do have a need for 90+ groups then there are lots of ways to get clients into those groups.
You can install and unmanaged client and then make it managed after the install.
You could install a client that joins the Default group and is then moved after install
You could script the install to copy the source files down and then grab whichever sylink.xml is appropriate to the system.

Essentially a client can be moved by simply stopping the smc service, dropping a sylink.xml and then restarting the service.
You do have to watch things if a client is already in a group on the server as you often have to delete them from the server to get them to move.
Look into sylinkdrop or sylinkreplacer although I have found sylinkreplacer extremely slow so I just use a script that utilises psexec and is a lot faster.

It is best to ensure clients are put into the correct group at install time.
I have seen a lot of places where the unmanaged clients that just dont get convereted into managed ones.
I would even go as far as creating a default install group with scans turned off, all your exclusions etc. etc. configured that clients join by default.
It is best to have them managed and connected with a very basic config and at least they end up in the console initially and can be moved manually if your scripting fails.

Z

Yeah I know I can copy new Sylink files to the install directory, but we do not want to keep creating new WISE packages.  We want to use 4 packages (Workstation 32, Workstation 64, Server 32, Server 64) and just figure out a good way to utilize all the different Sylink files during the install.

With sticking with all the groups, unmanaged to managed is not an option because I need the servers to join a group to get the individual exclusions. 

I can't move the clients manually after the install because many of these like I said would be taking place in the wee hours of the morning by a scheduled SCCM job (maintenance window for servers).

We use SCCM to do our distribution.  When we copied the source files locally then copied the sylink.xml file to that local install directory, SCCM quit the deployment with the "content mismatch" error.  SCCM is just how we do all our software and patch distribution.

You mentioned having a deployment client group with all scans turned off.  It is my understanding though that regardless of if you have scheduled scans turned on for a group or not, the scan that runs automatically after the client is installed is unavoidable.  If will run no matter what you do.  Is this nor correct?

Basically I am hoping there is an MSI property or something that can be used to specify a particular sylink.xml file to use instead of automatically using the one in the install directory.

Thanks guys.

Anyone who has done large scale deployments to servers:

Did you do them after hours?  If so, did you just have an exported pacakge for each client group?  If not, did you let them all go to one group, then manually move them later to appropriate groups?

Hello,

i did it like you said

I created for every client different setup packages. Which directed them into the right container.
I achieved this using the Deployment Wizard which is installed with the SEPM. There you can specify all options.

I created a Group named Clients and another one named Server (which has the policy no weekly scans whatsoever)
Then i created the setup packages for every group with 32bit and 64bit. I deployed most servers in the office hours because the restart of the server can occur later.  But be careful in 2 cases i had an automatic server reboot.

So you can deploy the clients via AD or your software distribution software and they arrive in the right groups.

Greets
Stephan

Yeah, I have a feeling I am going to have to have an exported pacakge for each client group, I was just trying to avoid that.  Thanks.

 I upgraded the majority of our servers after hours because some required reboots and they could not be rebooted during business hours. I just have one package for 32bit and one for 64bit then manually move them to the correct group. I really didn't want to have two install packages for each group so this really simplified it. The other reason I prefer to manually move them is because I've broken up the VM servers into groups of 5 (main Server group with multiple sub-groups) so that they can have independent weekly scan schedules to avoid having ALL of the VM servers scanning at the same time and slowing down the VM "farm"

so taking some advice from zer0, if I have a server deployment group and a workstation deployment group for the client pushes, if the server group has ALL server exclusions, whether they be SQL or Citrix, the the scan would run with the proper exclusions in place.  Then in the morning or whenever I could manually move the client to their permanent group.  Of course I would need to add a LU policy to the deployment groups with multiple GUP's configured and they would access the appropriate GUP based on subnet.

Prachand, Vikram, do you think this sounds alright?  Am i missing anything?

That is basically how I do it here and I have just started a deployment to 300,000+ endpoints.
If I could keep just workstations and servers as my groups I would be very happy but I realise there will have to be more.
The more you can simplify everything the better off you will be long term when it comes to management and upgrades etc.

The workstations group includes laptops and will have another couple of locations to handle them when they are external.
The desktops will never match the location rule so will never get those remote policies.

The scan that runs on installis just an active scan that targets memory and common infection points.
It should not do a full scan, and should be finished in a couple of minutes depending on the server.

There is a trade off between having servers in lots of seperate groups vs just having all the exclusions applied to all servers.
If you are excluding mdbdata or sql dirs then a file server doesn't have those folder locations and the exclusion doesn't apply.
So you can effectively keep all of your servers in the same group.

Just be mindful of adding any broad exclusions for a whole directory or drive that is common across all servers.
I am still amazed no one has written a virus that targets all of the most common exclusion folders the AV vendors and Microsoft have been recommending over the years.

Z