Martin Bengtsson

For security reasons, we have decided to join specific computers, serving a specific role to a workgroup instead of our domain. While being in a workgroup in the DMZ, we still had the need to manage them using ConfigMgr.

I had no previous experience in managing DMZ workgroup computers, so I had to gather the required know-how.

This is what I did:

• Listed the limitations regarding workgroup clients. (No Active Directory)
• Created the proper boundaries for the workgroups clients. (If no boundaries are created, all clients will be considered as a slow client)
• Made sure that port 80 (CM) and port 8530 (WSUS) are forwarded to through the firewalls to the new network.

As the workgroup clients are on their own network, and without DNS to give them information about which and where to locate a Management Point, we had to make following changes to the host files (C:\Windows\System32\drivers\etc) on the clients:

With these changes in place, you can install the CM client with following commandline: “ccmsetup.exe” SMSSITECODE=SITECODE SMSMP=yoursccmserver.fqdn.com

If installing the client from an OSD task sequence, you cannot use the SMSSITECODE property (We have a seperate OSD TS for these clients joining a workgroup).

When the client is installed successfully, you will be able to see the client in the SCCM console. Note that the client is not automatically approved (This can be changed to automatically auto approve all sorts of clients, but is not recommended)

After manually approving the client in the console, the client will start to download policies from the Management Point. (To speed up this process, you can restart the ccmexec service)

In the initial phase of getting this to work, it’s a really good idea to watch the proper log files, to see what actually happens, and in case of any errors, take the required actions.

These are some of the important client logs to consider:

LocationServices.log
ClientIDManagerStartup.log
Policyagent.log

Enjoy… 🙂

OBS: This post is primary about how to tattoo the registry with any given information, and then inventory it with SCCM2012.

In need of knowing when a client got it’s OS intalled/reinstalled? Read further. There is no built-in feature in ConfigMgr, that quickly enables you to find that piece information, which basically means we have to make our own.

In following post I will explain what I do, using hardware inventory in ConfigMgr 2012.

First off, we have to make sure that the information we need, in this instance, the date of OS deployment is created during the actual installation. This can be achieved in various ways. I choose to add an entry to the registry.

Running following commandline from within your OS task sequence does just that:

reg add “HKLM\Software\COMPANYNAME” /v InstallDate /t REG_SZ /d “%date%”

With this in place, we have what we need on the clientside. The command will leave a trace of the actual date of when the computer got installed.

Now we need to tell ConfigMgr how to use this, and for this I use hardware inventory.

Hardware inventory means changes to the configuration.mof. Download and use RegKeyToMof will make your life easier on this one: Download here

What you basically need to do, is to browse your way to the registrykey you wish to inventory. In this case HKLM\Software\COMPANYNAME\ and check off InstallDate. RegKeyToMof will automatically generate the necessary snippet of code to be inserted into the configuration.mof file and for your Client Settings in the ConfigMgr console.

Configuration.mof:

Client Settings:

Now update the client’s policy, run a new hardware inventory cycle and monitor the log files. InventoryAgent.log on the client, and dataldr.log on the server are relevant in this case. Datalgr.log vil start updating once the changes to configuration.mof has been done.

If everything goes as expected, you will be able to run a resource explorer on the client from the ConfigMgr console, and see something similar to this:

And finally from here, you will be able to use this information in queries or even build a report, and this way locate clients which haven’t been reinstalled for a long period of time.

Enjoy.

I just upgraded my SCCM 2012 environment to the latest R2-release and while everything seemed to be without obstacles, I ran into this error:

<![LOG[Failed to resume task sequence (0x800700EA).]LOG]!><time=”08:41:37.801+420″ date=”09-19-2013″ component=”TSMBootstrap” context=”” type=”3″ thread=”3256″ file=”tsmbootstrap.cpp:426″>EA)

My OSD Task Sequence got to install the OS and the SCCM client, and then just booted directly into the OS skipping the rest. No error was displayed, so I checked the SMSTS.log and saw the above error.

I was using boot images created from MDT 2012, which I thought would be OK in this case. But apparently it’s not – boot images created with MDT 2012 is no longer working and when I switched back to the default ones, my Task Sequence completed.

The new boot images comes with the new Windows 8.1 ADK (http://www.microsoft.com/en-US/download/details.aspx?id=39982) and R2 will upgrade them automatically.

The new boot images will look like this:

This blog-post from the ConfigMgr Team explains it all: http://blogs.technet.com/b/configmgrteam/archive/2013/08/23/reinstalling-cumulative-updates-in-configuration-manager.aspx

Very useful information, as you might end up in situation where a reinstall of the CU is required.

*UPDATE* This has been fixed in R2, and you are now able to select a deployment package from within the console *UPDATE*

Just a quick note on the above topic. I have created several Automatic Deployment Rules in my ConfigMgr environment, and was looking for a way to change which Deployment Package the updates was stored in. The console in SP1 doesn’t offer the opportunity, so I went to my favorite search engine and came across this blog post:

http://www.petervanderwoude.nl/post/changing-the-deployment-package-linked-to-an-automatic-deployment-rule-in-configmgr-2012/

Peter’s work is accepted to TechNet galleries:

http://gallery.technet.microsoft.com/Change-the-Package-linked-65662298

Some might claim that installing the SCEP client during OSD is an unnecessary step, but I’d claim otherwise.

Installing the SCEP (System Center Endpoint Protection) client as an step in your OSD task sequence, will provide instant protection against malware, whereas waiting for the automatic installation through the client policy, will leave the OS unprotected for the duration of the client policy polling interval + the time needed for the actual installation.

With that said, I’ll recommend to install the SCEP client during OSD. You can do that by separating the scepinstall.exe from the SCCM client installation folder (\\SITESERVER\SMS_<SITECODE>\Client\) and create a standard package and program running following command: scepinstall.exe /s /q /NoSigsUpdateAtInitialExp

Distribute the package to your distribution points, and add the step to your OSD Task Sequence as any other package.

/NoSigsUpdateAtInitialExp will prevent the installation to reach out to Microsoft.com for definitions updates, and therefore limit the WAN usage, which is considered good practice. Definitions should be installed from your Software Update Point:

There are several ways to install the SCCM client. As you know, it may be installed during OSD using a package, or the built-in push feature after discovery, but sometimes it might come handy to be able to install it using a script. (More about Client Deployment here: http://technet.microsoft.com/en-us/library/gg682132.aspx)

Nothing really fancy, just a plain .bat file containing following information:

“\\SITESERVER\SMS_SITECODE\Client\ccmsetup.exe” /mp:FULLY QUIALIFIED SERVERNAME SMSSITECODE=SITECODE

Replace everything in bold with your own details.