locked
Server 2003, SCCM Client and Endpoint Protection RRS feed

  • Question

  • Hi,

    We have a mixed environment of Server 2003 and Server 2008 servers.  I'm beginning testing a rollout of the SCCM 2012 SP1 client to those systems.  In Custom Client Settings, Ii deployed to the root of my server collection, i have the Endpoint Protection settings disabled ("Manage Endpoint Protection client on client computers" is set to "No").  There is only one other Custom Client settings policy that is deployed and i have verified it's not deployed to any of my servers.  The default client setting is applied, but i have a higher (1 for my setting, 10000 for the default client setting) priority on my collection  We currently have Symantec Endpoint Protection 12.1 installed on all the servers in my environment.  My issue is this:

    * deployed the SCCM client via the client push feature to 4 servers.  Two were Server 2008 R2 and two were Server 2003 SP2.

    * The two server 2008 R2 servers installed fine.    No issues so far that i can see, SEP 12.1 is still installed and working fine. 

    * The two server 2003 servers had SEP 12.1 uninstalled during the client install.  On one server, SCEP 2012 was installed.  On the other, SCEP was not installed, although it looked like it attempted and failed. 

    Has anyone else seen something like this?  I see some other threads with RDP issues with Server 2003 servers after installing the client, but nothing with SCEP. I am not ready yet to just deploy SCEP.  And i don't want it installing to Server 2003 boxes just yet either. 

    Thanks,
    J

    Friday, January 25, 2013 4:28 PM

Answers

  • Not sure how to categorize this, but just like with group policy, you really shouldn't enable or change non-default settings in the default client settings. You should create separate groups of client settings to change settings n specific target group groups of systems. For the above, the servers that installed SCEP probably did not get the custom client settings initially and thus acted upon the default client settings. Remember, collections are *not* updated in real-time so there are a lot of timing implications. If you don't want all of clients to have SCEP, you shouldn't enable it in the default settings. Not a bug, just a timing issue and a poor choice of implementation -- please don't take that as a dig or insult as that's not my intent because we all make mistakes even if we think we did everything correctly.


    Jason | http://blog.configmgrftw.com

    Monday, January 28, 2013 6:47 PM

All replies

  • You have to examine the logs to get an idea why it failed.

    Torsten Meringer | http://www.mssccmfaq.de

    • Proposed as answer by Sokoban3 Monday, January 28, 2013 1:30 PM
    • Unproposed as answer by Sokoban3 Monday, January 28, 2013 1:30 PM
    Saturday, January 26, 2013 12:04 PM
  • You can find the logs in C:\Windows\CCM
    Monday, January 28, 2013 1:30 PM
  • Ok.  Maybe I wasn't clear.  I don't want to know why SCEP failed the install.  I want to know why it tried to install on the Server 2003 boxes in the first place.  My custom client settings say to not manage endpoint protection on client computers.  It didn't try to push SCEP onto a Server 2008 box, but it did to a server 2003 box.  That screams out that it's a bug to me. 

    I've looked at the logs, on both my server 2008 clients and my server 2003 clients.  On the server 2003 client in the EndpointProtectionAgent.log file I see the command line to install SCEP.  On the Server 2008 clients, I don't see that.  I see in the event logs on both the Server 2003 client where it uninstalls SEP.  I see on both Server 2003 clients where it attempts to install SCEP.

    I've checked the SCCM client logs and I don't see anywhere where it mentions the custom client settings and whether it's supposed to install SCEP based on a the settings or not.  If someone could be more specific as to which logs to check and what to look for, that would help.  But frankly to just say check the logs isn't very helpful. 

    Monday, January 28, 2013 4:25 PM
  • Please list the default / custom client settings, the SCEP settings per client setting and which collection they are deployed to.

    Torsten Meringer | http://www.mssccmfaq.de

    Monday, January 28, 2013 4:28 PM
  • Custom Client Settings - Priority 1 - Deployed to my collection of Servers (840 Server 2003, Server 2008 and Server 2012 servers, only 2 of which have the SCCM client installed)

    Endpoint Protection Setting 

    -Manage Endpoint Protection Client on Client COmputers - No (subsequently all other settings are greyed out)

    Default Client Settings - Priority 10000 - zero deployments (deployed to all systems by default i believe)

    - Manage Endpoint Protection Client on client computers - Yes

    - Install Endpoint Protection client on client computers - Yes

    -Automatically remove previously installed antimalware software before endpoint protection is installed - Yes

    -Allow EP client installation and restarts outside MW - No

    -For Windows Embedded devices with write filters... - Yes

    -Suppress any required restarts after the EP client is installed - Yes

    -Allowed period of time... - 24

    -Disable alternat sources (...) for the initial definition update on client computers - No

    Monday, January 28, 2013 5:54 PM
  • Not sure how to categorize this, but just like with group policy, you really shouldn't enable or change non-default settings in the default client settings. You should create separate groups of client settings to change settings n specific target group groups of systems. For the above, the servers that installed SCEP probably did not get the custom client settings initially and thus acted upon the default client settings. Remember, collections are *not* updated in real-time so there are a lot of timing implications. If you don't want all of clients to have SCEP, you shouldn't enable it in the default settings. Not a bug, just a timing issue and a poor choice of implementation -- please don't take that as a dig or insult as that's not my intent because we all make mistakes even if we think we did everything correctly.


    Jason | http://blog.configmgrftw.com

    Monday, January 28, 2013 6:47 PM