Credential Guard without tools

When you deploy new machines with Windows 10 1607 and want to enable Credential Guards one of the things will want to do is prepare Hyper-V and Isolated User Mode so it is preinstalled so the end users do not get affected during enablement.

First off lets talk about Isolated User Mode, this was previously a stand alone feature that was required but starting with v1607 this has been included into the Hyper-V role. This means that there is one less feature for you to enable and keep track of.

Next we need to enable Hyper-V and the only features you need are the Hyper-V services and Hyper-V platform. This can be achieved using the Install Roles and Features step in MDT. In your sequence before the Windows Update step add a group and add the steps as show below.

Start with a Install Roles and Features step and then add a Restart Computer step and finish with Run Command Line step. Configure the Install Roles and Feature step as follow, check Hyper-V Platform, Hyper-V Hypervisor and Hyper-V Services.


For the Run Command Line step add the following information:
Dism /online /disable-feature /featurename:Microsoft-Hyper-V-Tools-All /Norestart


This will ensure that when the computer is finished deploying it will have the necessary roles and features for credential guard but end users won’t see the management tools.


Happy Deploying


Merge WIM into one – the space saver

I have gotten this question a couple of times “can i have two operating systems to choose from in one task sequence”. Well the correct answer to that is yes, but it takes up alot of unecessary space and if you are using ConfigMgr and need to download 2 wims instead of 1 well that adds alot of time.

What I would instead recommend is merging two Wim files into one, this will save alot of space and still give you the option to use different ref images in the same task sequence.

So how is this done?

First off you need to create two ref images. The most common senario for this is you have one with Office preinstalled and one without Office preinstalled. So if we look at how that looks you will get something like this:


In this case I am using Windows 10 ref images but this works just as well with Windows Vista, 7, 8 and 8.1 (all Wim based OSes).

So as you can see they are around 4-5GB in size. The next step now is to merge them. To help with this i have a small script that you can use.

What the script does is it takes one wim and mounts it. Then it applies the mounted wim into the other wim so you get two indexes and next it cleans up the mounted directory and finally displays the different indexes in the merged wim file.

You can download the script here: http://bit.ly/1TAcO8Q

When that is complete you get something looking like this.


As you can see the image is now a bit bigger but it has not doubled in size. This is due to the fact that when the wims are merged it will throw away all duplicate files to keep the file size down.

This method is the same method Microsoft have used when they have created Windows Server medias in the past containing core and gui versions on the same media.

The next step is to import this into whatever solution you are using (MDT/SCCM).

In this instance I have used MDT and it looks similar in SCCM but there are a couple of differentes. If you are unsure, drop me an email or pm and I can help you out.

So, import Operating system, custom image and point to the wim created erlier. When its done it looks something like this


If we look at the preferences for these two operating systems you can see that they both use the same file in the background but different indexes.


Now you can add another install operating system step and select different citeras to run the different steps. For instance, different blocks in CustomSettings.ini, some setting in the MDT database or add a new setting to the MDT database and use that. Use webservices and if the computer is this OU or AD group it should have office and if not it shouldn’t. The possibilities to create rules are as always limitless.

Happy deploying!


System Center Operations Manager – EventID 20070, 21016 & 20000

Recently we got a problem with our OpsMgr server where all the agents stopped reporting but still appear green in the console and all that is logged is event id 20000 on the Management Server and 20070 on the server with the agent. You get no alerts and no more clues to why this is happening. So in search for a fix for this I’ve seen several blogs about certificate issues, OpsMgr Gateway servers and Firewall issues. But no where does it say what to do in case you have this on all or some of you agents that are part of the domain, has been working and suddenly stopped with no apparent errors.

If above is not enough to make you go mad, reinstalling agents, adding new agents or flusing the health cache won’ help with. So lets start from the begning.

The server wich is beeing monitored. If you have this issue on multiple servers pick one and look at that one, don’t look at all servers in one go. So event ID 20070 and 21016.

Agent20070 Agent21016

This tells us that during communication with the Management server the agent has problems AFTER authentication. OK so one good thing, the agent can find the server and gets a response of some sort.

On the management server you have the issue of Event ID 20000

And this tells us that the agent should be in a pending state approval state. Ok so off to the console, check pending agents and 0, none, zip, nada. Well the agent have been working so lets check under Agents Managed.


Well this is strange, the agent should be in pending approval but isn’t and when looking at the agent is all green and saying everything is OK but we still get no alerts from them.

Everything then seems ok, agents are green, DNS is working. Management server is up and running, all services are running. Connection to SQL DB is ok. So here is the kicker there has been a change from OpsMgr 2007 to OpsMgr 2012. In 2007 and erlier versions you can put machines into Maintenance mode. They then temporarily stop reporting so you can do maintenance work, reboots and other fixes. In 2012 this has changed and maintenance mode can now be applied to any object. This means an agent can be up and running, the management server is up and running but the IIS on the monitored server is in maintenance mode so IIS won’t give you any alerts. And the same thing can then be done on the management server. The server is up but the port that accepts connections is in maintenance mode and thus does not accept any connections or generats any alerts.

So how do we find this since the console sure ain’t telling us anything about this and the event log isn’t giving of any clues
Powershell to the rescue! There is a couple of commands related to scom maintenance mode that can be used. First off is Get-ScomMaintenanceMode, this will list an objects in maintenance mode  but only with there guidnumbers and you might have servers that should be in maintenance mode. Instead we use Get-ScomMonitoringObject combined with a small filter that looks like this.

Get-ScomMonitoringObject | Where-Object { $_,InMaintenanceMode -eq $true }


This will give you a list of servers that has some or all of their objects in maintenance mode. Now you can start to figure out which of these shouldn’t be there.Next up since I had none of my servers needing to be in maintenance mode we run another small powershell command to reset maintenance mode.

Get-ScomMaintenanceMode | Set-ScomMaintenanceMode –EndTime (Get-Date) –Comment “Remove from maintenance mode”


This will get all maintencemode objects and set a new time to end the maintenancemode to “now”. You can after this run Get-SCOMMaintenanceMode to verify no more objects are in there. After this all the agents will start reporting in again.


Operations Manager – Clear Healthservice

I was recently at a customer where we installed Operations Manager and while installing we did notice some strange behaviors in some of the agents. As it turned out there was and old OpsMgr installation with the same management group name as the one we had chosen.

This meant that the agents always reverted back to the old server. To remove this behavior all references in AD where removed and the new server published new AD integration information. This is however not enough as you also need to clear the agent health cache and remove the old Management Group information from the registry.

To make this easier I wrote a script that using remote Power Shell connects to the computer/computers, stops the health service, clears the health cache, removes the registry entries and then starts the health service again.

The script can be downloaded here and is pretty straight forward. To run the script just enter a computername of the server where the agent is installed and the health cache will be reset. When used with the -ClearGroups switch it will also remove any references in the registry to all management groups.

For mor information on the script use get-help clear-healthcache.ps1

Please leave a comment if you find something that is not working or if you just like and use the script.