CMM 2012 R2 - ServiceWindowManager.log - Types of "Service Window for Type ="

ServiceWindowManager.log is a handy place to look on a client (C:\Windows\CCM\Logs) if you want to know what it thinks its maintenance window should be. It's a pretty simply log and fairly easy to figure out. The only bit which slightly stumped me was the 'Type' field:

Turns out this simply refers to the type of service window for which the log is displaying the details:

Value	Service Window Type	Description
1	ALLPROGRAM_SERVICEWINDOW	All Programs Service Window
2	PROGRAM_SERVICEWINDOW	Program Service Window
3	REBOOTREQUIRED_SERVICEWINDOW	Reboot Required Service Window
4	SOFTWAREUPDATE_SERVICEWINDOW	Software Update Service Window
5	OSD_SERVICEWINDOW	OSD Service Window
6	USER_DEFINED_SERVICE_WINDOW	Corresponds to non-working hours.

SCCM 2012 R2 - Applicaiton Catalogue Error - "Cannot Install or Request Software"

Problem:
You navigate to your application catalogue (http://servername/cmapplicationcatalog/) on a user's workstation. Select an application and click 'install'. Then up pops this error message:

You can browse the list of software in the Application Catalog and view your list of software requests. However, to install or request applications from the Application Catalog, you must use a support version of Internet Explorer and the Configuration Manager client must be installed and properly configured on your computer.

As a follow up, you navigate to the application catalogue log file (c:\Users\<username>\AppData and then search for ConfigMgrSoftwareCatalog.log) and see the followinf messages popping up:

[1][04/15/2015 12:17:40] :ApplicationDetailViewModel.InstallAppProgression-Error:Progress step CanUserinstall: Could not communicate with the client control properly. Error 0x1709.  Debugging resource strings are unavailable. See http://go.microsoft.com/fwlink/?linkid=106663&Version=5.1.30514.0&File=mscorrc.dll&Key=0x1709 0x80041003

Cause: 
Odds are there's something in Internet Explorer which is preventing the Application Catalogue from working correctly. 

Fix:
First check that the sccm html address has appeared in Trusted Sites. Open IE > Tools > Options > Switch to the Security tab > Highlight Sites and then open the Trusted Siters list and check your sccm server has appeared:

This is something which should happen automatically assuming you've defined the CCM Client Settings in the following way in your SCCM Admin Console:

The next thing to check is that Protected Mode isn't on since this will nobble the Applicaiton Catalog and prevent it from working. If your Local Intranet setting looks like this then you'll need to figure a way of changing it (Group Policy being the obvious choice):

Once you disable Protected Mode you should find the Application Catalogue kicks into life and stops throwing up error messages. 

SCCM 2012 R2 - Client Deployment - Client Cannot be Assigned to Site

Problem:
Having installed SCCM 2012 R2 you decide to push out a client to a machine. Watching the ccmsetup.log file (found in C:\windows\ccmsetup\logs), you are pleased to note everything seems to have installed as expected. When you open up control panel on the target machine, however, the "Actions" tab in the Config Manager Properties dialogue box is looking a bit sparse. In fact, the only things showing are 'Machine Policy Retrieval & Evaluation Cycle' and 'User Policy Retrieval & Evaluation Policy':

Next you navigate to the cmm log files on the client (C:\Windows\CCM\Logs) to see what's happening. Firstly you notice there aren't as many log file as usual:

Secondly, when you open LocationServices.log, you notice that the client is still trying to talk to the old site "LSVerifySiteAssignment : Client cannot be assigned to site":

Because the new client is still looking to the old site code, none of the post install ccm client config is being pulled down. The SCCM 2012 client can't talk to the 2007 site. 

Cause:

Something is causing the new client to look to the old site. The answer is fairly obvious in this case as the log file says:

"LSRefreshSiteCode: Group Policy Updates the assigned sitecode <xxx>, which is different than the existing site code <>. Will attempt reassignment."

Here, there is a Group Policy being applied to the machine which is forcing the new SCCM 2012 R2 client to look to the old site. Checking in group policy we find that the 2007 ADM template has been added, configured and applied to the client:

Thus each client will have the following settings configured in their registry under the 
"HKLM\Software\Microsoft\SMS\Mobile Client" registry key:

GPRequestedSiteAssignmentCode            =           S01
GPSiteAssignmentRetryDuration(Hour)      =           60
GPSiteAssignmentRetryInterval(Min)           =           12

Solution:

In theory, all you need to do is either change the setting on the group policy or set it to Not Configured. Since the ADM Template is part of a GPO Policy it should not tattoo the registry (unlike a GPO Preference which would)......

However, in my case simply setting the three settings to Not Configured and then applying the policy to the workstations made no difference to the registry. Thus, when it came to installing the 2012 client, all the workstation clients were still looking back to the old 2007 SCCM server. To fix this, you need to make an additional change in order to remove the three registry keys mentioned previosuly. On your 2007 SCCM server, do the following:
> Open notepad
> Paste the following code in:

reg delete "HKLM\Software\Microsoft\SMS\Mobile Client" /v GPRequestedSiteAssignmentCode /f

reg delete "HKLM\Software\Microsoft\SMS\Mobile Client" /v "GPSiteAssignmentRetryDuration(Hour)" /f

reg delete "HKLM\Software\Microsoft\SMS\Mobile Client" /v "GPSiteAssignmentRetryInterval(Min)" /f

> Save the file into the SCCM software share

> Open the SCCM admin console and create a new collection, program and advertisement to push the batch file out:

> Once the batch file has been deployed to all the workstations, use the admin console for SCCM 2012 R2 to deploy the new client to all workstations

> Sit back and watch all the new clients appear in SCCM 2012 R2

SCCM 2012 R2 - Reporting Services Point - Failed Install "The DataSource does not exist"

Symptoms:
You have SSRS installed on a different server from your SCCM 2012 R2 install. You can access the default SSRS site in Internet Explorer using the default url (http://reportservername/Reports). In SCCM, you add a new Site System and select the Reporting Services Point for installation.

On your SQL Reporting Services server, you encounter a whole bunch of error message in the srsrp.log:

Set configuration
Check state
Check server health.
Successfully created srsserver
Reporting Services URL from Registry [http://sqlreportserver/ReportServer_SQL2012/ReportService2005.asmx]
Reporting Services is running
The DataSource does not exist.  
[sqlreportserverlocal\SQL1] [SCCM_XXX] [ConfigMgr_P01] [sqlreportserver.LOCAL]
[SQL2012] [1] [] [XX\SCCM2012Server]
[1] [0]
Confirmed version [11.0.5058.0] for the Sql Srs Instance.
System.Web.Services.Protocols.SoapException: The item '/ConfigMgr_XXX' cannot be found. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ItemNotFoundException: The item '/ConfigMgr_XXX' cannot be found.~   at Microsoft.ReportingServices.Library.ReportingService2005Impl.GetProperties(String Item, Property[] Properties, ItemNamespaceEnum itemNamespace, Property[]& Values)~   at Microsoft.ReportingServices.WebServer.ReportingService2005.GetProperties(String Item, Property[] Properties, Property[]& Values)
Extract resource language packs if exists
Loading localization resources from directory [D:\SMS_SRSRP\SrsResources.dll]
Looking for 'English (United Kingdom)' resources  
Looking for 'English' resources
Found resources for 'English'
System.Web.Services.Protocols.SoapException: The item '/ConfigMgr_XXX' cannot be found. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ItemNotFoundException: The item '/ConfigMgr_P01' cannot be found.~   at Microsoft.ReportingServices.Library.ReportingService2005Impl.SetProperties(String Item, Property[] Properties, Guid batchId)~   at Microsoft.ReportingServices.WebServer.ReportingService2005.SetProperties(String Item, Property[] Properties)
System.Web.Services.Protocols.SoapException: The permissions granted to user 'NT AUTHORITY\SYSTEM' are insufficient for performing this operation. ---> Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: The permissions granted to user 'NT AUTHORITY\SYSTEM' are insufficient for performing this operation.~   at Microsoft.ReportingServices.Library.ReportingService2005Impl.CreateFolder(String Folder, String Parent, Property[] Properties, Guid batchId)~   at Microsoft.ReportingServices.WebServer.ReportingService2005.CreateFolder(String Folder, String Parent, Property[] Properties)  
(!) SRS root folder was reported missing
Failures reported during periodic health check by the SRS Server sqlreportserver.LOCAL.
Registry change
Waiting for changes for 1 minutes


Elsewhere in SCCM, the Site Status > Reporting Services Point says:

SMS_SITE_SYSTEM_STATUS_SUMMERIZER: Site System Status Summarizer detected that the availability of the "Reporting services point" role on server "\\NA-SQLR01.in.tna.local" has changed to Failed.

And the last message from the SMS_SRS_REPORTING_POINT Component Status is "Site Component Manager successfully installed this component on this site system"

Also, when you open the SSRS website you notice that no SCCM folder has been created:

Cause:
Insufficient permissions on the install account. Assuming the Reporting Services Point is installed on the same server as the site server role (which it will almost always have to be), then the local System account will need the appropriate security rights over SSRS since this is what install and configures the Reporting Services Point.

Resolution:
Uninstall the Reporting Services Point using SCCM admin console.

Open up Internet Explorer and navigate to the default reports page. From here you'll need to make an additon to the following areas:

Add the NT AUTHORITY\SYSTEM account to the Permissions areas in:

Site Settings > as a System Administrator > Click Apply

Folder Settings >  as a Content Manager > Click Apply

Re-install the Reporting Services Point and then keep an eye on the srsrp.log, the errors which previously popped up should now be conspicuous by their absence:

Furthermore, the ConfigMgr_XXX folder should now appear in the SSRS website:

After a couple of minutes, if you switch back to your SCCM admin console and navigate to Monitoring > Reporting > Reports you should see a whole bunch of reports have appeared:

SCCM 2012 R2 - Content never appears on Distribution Point, stuck 'In Progress'

Problem

You try deploying an application to a remote distribution point, but nothing seems to show up. The little pie chart of progress refuses to turn green for the DP you're trying to deploy to:

Furthermore, checking the Content Status shows that the DP is waiting for you to pre stage the content.

Cause:

Somewhere there's been a mix up between how you think content should be distibuted (i.e. automatically) and how the new DP thinks it should be getting content (i.e. manually).

Fix:

You need to change the distribution point settins or the applicaiton deployment settings...or you might even need to change both.

The DP

If the Distribution Point has been set to be "Enabled for prestaged content" then it will be expecting content to be manually copied to it. Untick this box to remove it's presumption that all content will be prestaged:

The Package

If the package has had its 'Prestaged distribution point settings' set to manually copy the content to the dp, then the dp will, quite reasonably, be expecting you to manually copy the content onto the dp. Open the properties of the package and make the change under the Distribution Setting tab:

Try re-distributing the package with the new settings in place and you should find it now automatically deploys to the DP.

SCCM 2012 R2 - Configuration Manger Management Point Fails to Install - Error 1603

Management Point install fails - Error 1603+

If you find yourself encountering this frustratingly generic error message, log onto the server which you're attempting to install the MP on and navigate to %installdirectory%\SMS\Logs. Open up the mpmsi.log and have a hunt for “return value 3”. Surrounding this error will be a fairly descriptive exaplanation of what the root cause of the 1603 issue actually is. Remediate the issue according to whatever the mpmsi.log suggests. Then you just waitfor the role to reinstall (which should kick off every hour). To move things along, you can restart the SMS Executive Service.

SCCM 2012 R2 - Deploying a Management Point to Windows 2008 R2 server - HTTP test request failed, status code 500

Problem:

After remotely deploying a mangement point from your 2012 R2 primary server, the management point appears to install ok (i.e. the mpcontrol.log file appears in the %installlocaiton%\SMS\Logs folder). However, when you open the mpcontrol.log file, you notice that large portions of it are a vivd shade of red:

The key lines here are:

Call to HttpSendRequestSync failed for port 80 with status code 500, text:Internal Server Error

HTTP test request failed, status code 500, 'Internal Server Error'

Also, there may be some mention of a failure to connect to the SQL Server, e.g.

Failed to get connection to the configured SQL Database

Failed to connect to the configured SQL database.

Other Symptoms

navigating to http://servername/sms_mp/.sms_aut?MPList returns a blank page with a HTTP 500 error

Fixes to Try:

1] Assuming the MP and the SQL DB are in different parts of the network, ensure the firewall is allowing connections from the MP to the SQL DB (on TCP 1433 is the default). If the MP cannot talk to the SQL DB then this will cause all of the above errors to occur. 

2]  If you are only seeing the "Call to HttpSendRequestSync failed for port 80/443 with status code 500, text: Internal Server Error" message then you will need ASP.NET v4 with IIS (this doesn't need to be done in 2012 since this is enabled by default). Open an elevated command prompt and then enter the following:

cd /d %windir%\Microsoft.Net\Framework64\v4*
aspnet_regiis –i –enable

In a similar vein, you may also need to enable the 64-bit mode because IIS is configured to run in 32-bit mode, the ASP.NET installation does not create the ASP.NET registry keys in the 64-bit registry. To resolve this issue, type the following command in an elevated command prompt:

cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

Other very worthwhile links to check out:

http://scexblog.blogspot.co.uk/2013/12/call-to-httpsendrequestsync-failed-for.html
http://anoopcnair.com/2014/07/07/sccm-mp-internal-server-error-iss-call-httpsendrequestsync-failed-port-80-status-code-500/
http://systemcenterblog.hardac.co.uk/2013/04/note-to-self-configmgr-2012-sp1.html