SCCM 2012 r2 in a closed network

Last time I installed an SCCM 2012 r2 environment for a client, they have a special application that is running in a separate domain and have no internet access at all. I had only a few firewall openings that were needed to running this application.

I already had WSUS installed against an upstream server for indexing. Because the internet access to all servers were cutoff I needed to find a way to download all Critical and Security updates for all windows servers and clients in that environment. Normally you use WSUS only for indexing, SCCM 2012 r2 will download the requested updates directly from Microsoft Update Services. You could also download manual all required updates from the Microsoft Update catalogues and import them into the SCCM 2012 r2 environment. This will be a lot of work every month to do so..

My WSUS server have access to the upstream server and the upstream server already downloaded all required updates.

I created a rule within WSUS to auto approve all security and critical updates and download these automatically to specific directory. In SCCM you could import required updates from a file share so the next thing I created an ADR, in that ADR i told SCCM 2012 r2 to not download the updates but import them from a file share. I pointed to the file share where I downloaded the updates from WSUS.

SCCM accept these updates and distributed them to my clients.

SCCM Client FIX, WMI Repository corruption

The WMI Repository is the data database “%windir%\system32\wbem\repository” That stores meta-information and definitions for WMI Classes. In some cases the repository also stores static class data as well. If the Repository becomes corrupted, then the WMI service will not be able to function correctly. SCCM is build to use the WMI repository to work.

If you suspect that the WMI repository is corrupted the last thing you should do is rebuilding and deleting the repository, †it could damage your windows installation and let fail applications. Other steps need to be taken first to confirm that the repository is truly corrupted. A large repository could cause problems and†sometimes be interpreted as a corrupt repository, which is not always the case. If issues are due to a large repository, rebuilding the repository is currently the only method available to reduce the repository size.
Before you take anysteps make sure you used WMIdiag†to report any problems with the repository.
If repository is found to be inconsistent:
††† a. For Vista and newer, run from elevated command prompt:
Winmgmt /salvagerepository
Note†this command will take the content of the inconsistent repository and merge it into the rebuilt repository if it is readable
If the above doesnít work, then run:
Winmgmt /resetrepository
Note†this will reset repository to the initial state when the OS was first installed.
Note†In Windows XP and Windows Server 2003 there is no posibility to use switches for repairing the†repository.
Warning: Rebuilding the WMI repository has resulted in some 3rd party products not working until their setup is re-run & their MOF re-added back to the repository.
If /salvagerepository or /resetrepository does not resolve the issue, then manually rebuild repository:
  1. Open a CMD prompt with elevated privileges
  2. Use “net stop winmgmt” to stop the WMI services
  3. Rename the repository folder:† C:\WINDOWS\system32\wbem\Repository to Repository.old
  4. CD windows\system32\wbem
  5. for /f %s in (‘dir /b /s *.dll’) do regsvr32 /s %s
  6. Use “net start winmgmt” to start the WMI services
  7. cd /d c:\† ((go to the root of the c drive, this is important))
  8. for /f %s in (‘dir /s /b *.mof *.mfl’) do mofcomp %s
  9. Reboot the server or client