https://blogs.technet.com/b/configmgrteam/archive/2013/02/11/support-announcements-for-february-2013.aspx

However, when attempting to install Config Manager 2012 SP1 to an SQL 2012 SP1 Server I was faced with the following error:

I double-checked that my SQL Server version was higher than SQL Server 2012 CU2, and could see that version 11.0.3000.0 is indeed SQL 2012 SP1.

This was a simple installation, with a local SQL database on my Config Manager Site Server using the default instance and I did not fancy having to uninstall and re-install SQL so I decided to investigate further. I initially thought that this could be a connectivity with connecting to the SQL server, so I created a .UDL file on my desktop and used this to test the connection to SQL.

The connection was successful, so I decided to take a trace using Process Monitor to try to work out why the installation was failing. I fired up Process Monitor and recreated the error in the Config Manager installation. This gave me a trace with several thousand lines and so I applied some filtering in Process Monitor to try to narrow in on the interesting results. The first filter was to exclude all values ‘SUCCESS’

This narrowed the results down considerably and I noticed several queries for the following registry key:

HKLM\SOFTWAREMicrosoft\Microsoft SQL Server

I created a filter in Process Monitor to return all of the results for this registry key:

The results showed me several registry values that were listed as ‘NAME NOT FOUND’

I was then able to compare the registry for my failing installation with a working system and add the information to the registry that the Config Manager 2012 SP1 setup was missing.  Here are the values I added to the registry in order to get the Setup to complete:

After adding these keys and values, setup completed successfully.

Attached is a text file containing a copy of the missing registry keys

SQL.txt

Consider the following script: 

It imports the new PowerShell module and then changes directory to the newly created Config Manager drive. When I run this script under my own user account,everything works as expected:

But when i run the same script as a Service Account, or as the Local System Account it no longer works!

 A bit of further investigation reveals that the module has been imported, and the Config Manger Provider has been created, although the drive is not properly mounted. 

So what is happening here? It turns out that the Configuration Manager PowerShell module is digitally signed, and the user running the script must install the certificate that the module was signed with before they can use it.  This can be done be launching Config Manager as the user that will be running the script. To do this, right click on the Config Manager console and choose ‘Run as a different user’:

Once the Config Manager console has opened, then go to ‘Connect via Windows PowerShell’ :

PowerShell will start and ask you if you want to trust the software form this publisher:

If you choose to trust the content then the PowerShell module is imported and the Config Manager drive is created in PowerShell:

If I then go back to and re-run my script, this time I find that it works!

Alternatively, if you are trying to schedule scripts to run as the ’Local System’ Account then it is possible to manually install the certificate to solve this problem. Right click the PowerShell Module file ‘ConfigurationManager.psd1’ and choose ‘properties’ and then ‘Digital Signatures’. From here choose ‘Install Certificate’

 Import the certificate into the ’Local Machine’ store

And place it in the ‘Trusted Publishers’ store.

Once the certificate is installed, the Local System account can now run the new Configuration Manager cmdlets!

Upon reviewing distmgr.log I could see the following errors listed for each Distribution Point:

Cannot establish connection to ["Display=\\SccmServer01\"]MSWNET:["SMS_SITE=CEN"]\\SccmServer01\

Error occurred.

I restarted the Site Server and the problem disappeared, but after a couple of days the same errors were being logged again and it was no longer possible to distribute packages.

I tried to connect manaully to the remote server and recieved the following error:

Error code: 0x80070035
The network path was not found.

On further investigation I found that:

• I could ping the server
• Name resolution was working correctly
• I could connect to the ip address of the distributions points
• I could connect to the fqdn of the distribution points

Initially i thought this maybe a kerberos issue, as connecting via the IP address made an entry in the Security Event log showing that NTLM was being used. If i started KLIST.EXE under the local system account i could see that there was no kerberos ticket listed for the remote Distribution Point. At this point i took a network trace but could not see any network traffic when i tried to connect to the short name of the remote DP \\SCCMSERVER01

It turned out that the Site Server was running Windows 2008 R2 and there is a bug in Mrxsmb10.sys which caches credentials incorrectly in the SMB redirector. Installing KB2194664 fixed the problem.

You can read more about that hotfix here:

https://support.microsoft.com/kb/2194664

Hope this saves you a few hours troubleshooting !