SCEP Definition updates fail to update manually

System center Endpoint Protection client on machines fail to update manually with error message: Virus and spyware definitions update failed with error code 0x80248014

Upon investigation it is found that you need to have internet access on client machines and that has to be defined in the SCEP client settings to go to alternate update sources other than SCCM server which is hosting WSUS server role; that is  definition update source as updates distributed from Microsoft update sources.

In case the above setting is not present then there is alternate solution for this issue which is described under Microsoft article: https://support.microsoft.com/en-us/kb/935934#/en-us/kb/935934 simply download this KB and manually install on the machine which will fix this issue but this is a one time fix.

If you want your SCEP clients get updated when you want to click on update button on SCEP client applet without the above error then you have to get the windows update setting changed in order to assist your client in this scenario, follow the following settings which is described under: https://support.microsoft.com/en-us/kb/2832355#/en-us/kb/2832355

1. Open Control Panel
2. Click System and Security
3. Click Windows Update
4. Click Change Settings
5. Check the checkbox "Give me updates for other Microsoft products when I update Windows"
6. Click OK

Note: I assume you have the infrastructure set up to take care of the definition updates using SCCM-WSUS the normal way.

Errors on software updates deployment through SCCM

There were some machines where we saw SCCM client communications wasn’t happening from last couple of months and the number was quite large. We had to carry out the analysis for that and we have been asked to suggest the solutions based on our findings, here’s what we found after analysing 40-50 odd machines.

Common errors found are as below

1. Errors in execmgr.log and rebootcoordinator.log Failed to instantiate UI Server with error 80004005

2. Errors in certificate maintenance.log ‘CCMDoCertificateMaintenance() failed (0x800703fa).’

3. Errors in WUAhandler.log ‘Failed to Add Update Source for WUAgent of type and id Error = 0x8007000d.’ and 'Unable to read existing resultant WUA policy. Error = 0x80070002' and 'Unable to read existing resultant WUA policy. Error = 0x800703fa' and 'Group policy settings were overwritten by a higher authority (Domain Controller) to: Server and Policy NOT CONFIGURED'

4. Errors in updates handler.log ‘failed to download update Error = 0x800705b4'

5. Errors in windowsupdate.log Failed to save WUAgent policy with updated WSUS Server. Error = 0x80070070

6. Errors in updatesdeployment.log 'Failed to get message id in failed progress state, error = 0x80040200' and 'Job error (0x80070070) received for assignment ' and 'Execute- Failed at AddUpdateSource, error = 0x80070070'

7. Event viewer logs: The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

Hence it was apparent that the sccm clients had issues and it was all pointing out towards software updates components, my initial guess was that either machines  were not rebooted after software updates installation or they were force rebooted during the installation phase, hence we checked the time stamps for reboot coordinator along with software updates deployment schedules. We rebooted couple of machines and they started functioning properly, we tried services restart which also worked on few machines, we then found a hotfix for the above mentioned errors and deployed the same on some machines which fixed the issue. Based on our finding and troubleshooting results we suggested following

 Suggested Solutions:

1. Reboot machine

2. Check if the machine reboot has fixed the issue

3. If not restart services i.e. SMS Agent Host, Windows update, WMI service

4. Run a script to reset windows updates component and restart services

5. Check the logs and based on errors try Installing hotfix:KB947821

6. Analyse the logs again and initiate client repair if required

7. Analyse the results and take a call on WMI repair if required

References:

http://community.spiceworks.com/scripts/show/2300-reset-windows-updates-powershell

http://www.zdnet.com/microsoft-releases-fix-for-windows-update-corruption-errors-7000026582/

http://support.microsoft.com/kb/947821

Unapproved machines throw Errors on SMS_MP_CONTROL_MANAGER

ISSUE DESCRIPTION:

We had an issue where unapproved SCCM clients threw errors on SMS_MP_CONTROL_MANAGER as “MP has rejected a policy request from GUID:XXXXXXXXXXXXXXXXXXXX because it was not approved. The operating system reported error 2147942405: Access is denied.”

The environment running on System Center Configuration Manager 2007 R2 in mixed mode and client approval setting as following 

Possible Solutions: 

To make the client get approved by any means

Solutions suggested by colleagues: Client repairs, Client reinstall or manually approve clients

Initial Analysis:

1.        Checked MP-IIS logs for one of the machine which threw these errors on with IP address

2014-03-28 00:03:41 W3SVC 1 00.00.00.00 GET /SMS_MP/.sms_pol GHJREEVJ JHGE 80 - 1 00.00.00.00  SMS+CCM 200 0 0

2014-03-28 00:03:41 W3SVC 1 00.00.00.00 GET /SMS_MP/.sms_pol GHJREEVJ JHGE 80 - 1 00.00.00.00  SMS+CCM 200 0 0

2014-03-28 00:03:41 W3SVC 1 00.00.00.00 GET /SMS_MP/.sms_pol GHJREEVJ JHGE 80 - 1 00.00.00.00  SMS+CCM 200 0 0

2.       Checked  MP_registrationmanger.log   

This showed lots of instances “Certificate issued to 'SMS' has expired”  on MP_RegistrationManager though it wasn’t for the above machine GUID.

Certificate issued to 'SMS' has expired.        MP_RegistrationManager        28/03/2014 07:13:16        25900 (0x652C)

MP Reg: Registration request body is invalid.        MP_RegistrationManager        28/03/2014 07:13:16        25900 (0x652C)

MP Reg: Registration failed.        MP_RegistrationManager        28/03/2014 07:13:16        25900 (0x652C)

MP Reg: Message Body : <ClientRegistrationRequest><Data RequestType="Registration" TimeStamp="2014-03-28T07:23:16Z" SMSID="GUID: GHJREEVJ JHGE -108C1AEE374D"><AgentInformation AgentType="0" AgentVersion="4.00.6487.2000"/><Certificates>

Certificate issued to 'SMS' has expired.        MP_RegistrationManager        28/03/2014 07:23:16        40144 (0x9CD0)

MP Reg: Registration request body is invalid.        MP_RegistrationManager        28/03/2014 07:23:16        40144 (0x9CD0)

MP Reg: Registration failed.        MP_RegistrationManager        28/03/2014 07:23:16        40144 (0x9CD0)

3.       Checked Clientauth.log

This also showed messages like 'Message rejected due to signature verification failure.'

 CCMValidateAuthHeaders failed (0x80040213) to validate headers for client 'GUID: GHJREEVJ JHGE '.        ClientAuth        24/03/2014 06:27:42        16808 (0x41A8)

Message rejected due to signature verification failure.

ClientID: GUID: GHJREEVJ JHGE

Actions Taken:

1.        Connected to the client machine checked SMS certificate showed as not expired. But I suspected the issue with certificate.

2.       I tried deleting the certificate and re-registering the client which fixed the issue.

Hence there wasn’t need to approve the client manually. Monitored the component status SMS_MP_CONTROL_MANAGER for 2-3 hours and those messages disappeared.

References:

1.        This blog has wonderful script to work on such unapproved machines:

         CHRISTJAN'S IT MINUTES  http://itminutes.net/?p=240

2.       Technet Discussion Forum

http://social.technet.microsoft.com/Forums/systemcenter/en-US/23eddaf7-3f65-47f3-ab23-72e0be6eeb67/mp-has-rejected-a-policy-request-from?forum=configmgrgeneral

Failed to get client version for sending messages to fsp.

I have a lab set up for System Center Configuration Manager 2012 server with SP1 upgraded, set up installation was successful with all the site system roles updated and configured.

When I try to push ccm client on Windows 7 machine(x64 bit) through client push installation method it gave error as “failed to get client version for sending messages to fsp” along with “Failed to get DP locations as the expected version Error 0x87d00215” these errors were found on ccm.log file on client machine and on site server ccm.log gave only error as “enable to connect to WMI root’ which rectified after adding site server machine name on administrators group on client machine and after editing system account settings on distribution point.

After doing some search on Google about this particular error I thought it could be because of the known issue stated on internet which said “This is a known issue in SP1 when installing the 64bit client. You will need to apply this hotfix to your site server and update the ConfigMgr installation package on your DP's” hence I have downloaded the hotfix available for the same from Microsoft website: http://support.microsoft.com/kb/2801987 applied the hotfix on site server machine which updated the client packages then tried to re-push the client package but it gave the similar errors on ccm log files. I checked distmgr.log file for to check for any traces there which said “failed to process package CA00000#”

Therefore I had decided to test this by removing the DP for package assignment hence

1.       Removed the DP role from the Primary Site server – checked the DistMgr.log for the removal.

2. Re-deployed the DP role to the Primary Site server – checked  the DistMgr.Log/ Distribution Point Configuration State for the installation

       Somehow this fixed the issue, it installed the cm client on windows machine successfully.

“SCCM2012SP1 -Error 3364 on SQL 2012SP1 mount points”

 “SCCM2012SP1 -Error 3364 on SQL 2012SP1 mount points”

 

MOUNT POINTS:

Mount points are useful to add volumes without adding separate drives for them which are robust against system changes. The beauty of mount points is that one volume point can have multiple volume points giving system administrator ability to expand the storage capacity easily. Disk management utility can be used to assign mount point folder path to the drive.

ISSUE:

 

SCCM2012SP1- Error 3364 on SQL 2012SP1 mount points.

 

CAUSE:

 SMS_HIERARCHY_MANAGER “Hierarchy Monitor detected that the Database on drive is running out of space on mount points.

Though mount point runs out of space but volume drive which it points usually would have huge amount of space, Hence We need to force the configuration manager to ignore such messages through state message filter rules.

 

RESOLUTION:

Following steps can be used to create such state message filter rules on SCCM 2012 enforcing them

·        Log on to SCCMPrimary Site Server , Under Administration tab select Sites, right click on site listed and select Status Filter Rules

·         When new window opens select Create, provide details like Site Code, System, message ID(3364 here) and click next

·         Check options Do not forward to status summarizers and Do not process lower priority status filter rules and click next and ok

·         Now under Status Filter Rules you will find the rule just created ; select the rule created and increase it priority to 1 (Highest )

 

 

SCCM 2012 SP1 Client Push Error for x64 bit client

      

        Error : Failed to get client version for sending messages to fsp

I have a lab set up for System Center Configuration Manager 2012 server with SP1 upgraded, set up installation was successful with all the site system roles updated and configured.

When I try to push ccm client on Windows 7 machine(x64 bit) through client push installation method it gave error as “failed to get client version for sending messages to fsp” along with “Failed to get DP locations as the expected version Error 0x87d00215” these errors were found on ccm.log file on client machine and on site server ccm.log gave only error as “enable to connect to WMI root’ which rectified after adding site server machine name on administrators group on client machine and after editing system account settings on distribution point.

After doing some search on Google about this particular error I thought it could be because of the known issue stated on internet which said “This is a known issue in SP1 when installing the 64bit client. You will need to apply this hotfix to your site server and update the ConfigMgr installation package on your DP's” hence I have downloaded the hotfix available for the same from Microsoft website: http://support.microsoft.com/kb/2801987 applied the hotfix on site server machine which updated the client packages then tried to re-push the client package but it gave the similar errors on ccm log files. I checked distmgr.log file for to check for any traces there which said “failed to process package CA00000#”

Therefore I had decided to test this by removing the DP for package assignment hence

1.       Removed the DP role from the Primary Site server – checked the DistMgr.log for the removal.

2. Re-deployed the DP role to the Primary Site server – checked  the DistMgr.Log/ Distribution Point Configuration State for the installation

       Somehow this fixed the issue, It installed the cm client on windows machine successfully.

There are currently no logon servers available to service the logon request

 

 

Error : "There are currently no logon servers available to service the logon request" 

After joining the machine to the domain when I tried to login for the first time with domain administrator credentials it said "There are currently no logon servers available to service the logon request" and yes again I had to Google about the error and try resolving the error most of the solutions available online spoke about WINS database entries for authentication and domain controllers entries with NetBIOS names along with WINS server. I tried the following things to get the issue fixed.

1.        Rebooted machine

2.       Logged in with local administrator account

3.       Disabled firewall for testing

4.      Tried to ping the Domain controller it pined and was able to resolve domain name

5.       Disconnected the machine from domain and reconnected again

6.      Rebooted machine again and tried to login with domain user as earlier.

This fixed the issue though but I am not sure if this has anything to do with firewall settings or may be it takes some time to update entries on DC or DNS server after adding the machine to domain and trying to login with domain credentials for the first time.