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.

Refreshing State Messages SCCM 2012 R2

Recently I worked on the reporting service of SCCM 2012. I noticed that some client did not jet report their Compliance state back to SCCM 2012. Because of demanding reports back to our security officers I needed a faster and better way to get the Compliance reports in order.

SCCM comes with a fairly extensive set of pre-configured reports to provide information about the state of your infrastructure.  There are different types of reports to become familiar with, but the ones we care about here can be found under Monitoring\Reports\Software Updates A.

If you don’t see this in your environment, it’s likely you are either viewing a Site Server that is not set up with the Reporting Service Point role.  If this role is set up on another Site Server in your environment, target the Admin Console there instead.  If not, the following article goes through the process of setting up Reporting Services in your SCCM hierarchy: Configuring Reporting in Configuration Manager

What is the problem?

SCCM can only report what it knows, the way SCCM determines what should be in a report is through state messages sent by its managed devices. The state messaging system is fairly complicated.

The idea is that for some reason or other (network hiccup, etc.) the state messages relating to a particular compliance setting did not make it to the Site Server, which has resulted in the Compliance report showing inaccurate information.  By default, state messages should be resent every 30 days from all managed devices so any issues detected should resolve themselves over time.  But in practice, I have found that sometimes it’s necessary to give the state message system a jump-start in order to resolve the reporting discrepancy.

On my way to get a solution to this I came across a TechNet blog describing the above problem, the old fashion way to solve this issue is to use a VB script that forces the State Messaging system to report back to the SCCM Site Server. Also a problem with SCCM 2012 is that there is no official documentation available for publishing VBScript that run automatically on managed devices.. Of course you could make a scheduled task on every server. But if you mange several hundred or even thousands systems. That will be an impractical solution.

What about PowerShell??

When I search on the Internet I came across a small PowerShell script that does the job, the first poster that created this small script had only a two-line solution, So why not try it? right below you will find the script, save this as yourscripname.ps1

The first two lines is where the actual action occur, these will force the managed device to report back to the SCCM site. the third and forth line will generate an event in your event viewer, that is the way you could view if your script run successfully.

You could also check out the UpdateStore.log file on your SCCM client log file folder:
Opening the log file after running the script, we should see the following:

Initiated refresh of update compliance to site server.    UpdatesStore    2/23/2015 6:03:10 AM    7332 (0x1CA4)
Successfully called refresh of update compliance from automation object.    UpdatesStore    2/23/2015 6:03:10 AM    13484 (0x34AC)
Message received to resend all update status, processing…    UpdatesStore    2/23/2015 6:03:10 AM    14184 (0x3768)
Successfully raised Resync state message.    UpdatesStore    2/23/2015 6:03:11 AM    14184 (0x3768)
Resend status completed successfully.    UpdatesStore    2/23/2015 6:03:11 AM    14184 (0x3768)

If this information is found at the same time as the script has run, we can say with confidently that it has done what we asked. From here, the only thing left to do is verify the Compliance report is now reporting correct information, which can be easily done by re-running the report.

Creating a Package:

open your SCCM Admin Console and browse to: Software Library\Application Management\Packages and right-click the Packages node.  Select Create Package and enter the following information

The first you need to enter some basic information the Wizzard will help you trough,

Name of your package.. I used ReSync Package – PowerShell
Enter your source directory (note that this source should be a network share and everyone permission need to be set as read)
On the next page, select ‘Standard Program’ (assuming we are using a client computer and not a device such as a Windows phone):
After selecting the Standard Program, we need to enter information on the script and how we want to run it.  The following screen provides that detail
image_thumb_05A7D343finish all other steps that the wizard require. I did not need to change any default settings in the package.

And deploy the package to your preferred device collection for testing.

 

 

 

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