The idea for this blog post was born during the week of MVP Summit at Microsoft in Redmond (March 5-9). I realize that depending on who you talk to they have different point of views on things. The view on “co-management” is a great example.

The purpose of this blog post is to present the options that exist for organizations moving to modern management. “Co-management” is the door opener and path for moving to modern management.

Why modern management?

Modern management is what I would say moving away from on-premise dependencies, creating a more flexible and mobile workplace and more cost-efficient management of Windows devices. This means doing things in new smart ways rather than keep doing them as you’ve done them for the last “100 years” or so. Why would you stop doing what you are doing and start doing things in new ways? Well, one is to save time for IT as well as end users and as time is money, you will be able to reduce costs in your organization. It’s also about not reinventing the wheel, which is what basically every organization is doing today in some sense.

Some practical examples is doing a F12/PXE deployment of machines as soon as they come in to the organization. Think new, and stop doing reference image building and stop certifying hardware and use modern deployment tools such as AutoPilot and Intune to save time and modernize the deployment process.

Another example is that you can reduce complexity and remove infrastructure, say for instance patching. Dismantle old WSUS servers and do patching via Windows Update for Business, which means relying on existing Microsoft infrastructure rather than downloading everything from Microsoft, approving patches, distributing patches etc. Again, do not reinvent the wheel and repeat what Microsoft is already offering in terms of infrastructure.

There are many more examples but I think you get the idea of modern deployment and management, stop doing things the way you’ve always done them and think new.

Introduction and definition of “co-management”

At the Microsoft Ignite conference in September 2017, Microsoft announced what is called “co-management”. “Co-management” is the first and fundamental step on the way to modern management to be able to use existing Windows devices and configuration “as is” but at the same time add a modern management tool. After doing that you can start the switch to modern management, as the switch to the modern world will not be done overnight for most organizations.

Now, “co-management” means different things to different people. My view on “co-management”, regardless if the customer is using ConfigMgr or not, is to keep your Windows client “as is”. With that I mean Active Directory joined and configured via GPOs and then adding MDM-enrollment to that to be able to start doing new configuration via MDM. For the sake of making “co-management” clear I’ve chosen to divide the customers into two, the ones with ConfigMgr and the ones without it.

And as a note, the MDM tool to use for modern management is preferably Microsoft Intune (part of the Enterprise Mobility+Security suite).

Fundamental thoughts

My idea is that once you’ve decided to go down the path to modern management – no more and I mean no more work whatsoever should be put into adding new stuff to your legacy solutions. That includes not making scripts, configuration and applications deployed or configured via on-premise Active Directory or ConfigMgr. Instead, you do this in the modern management tool (if possible). Focus one hundred percent on moving the current resources to the modern management world instead!

Goals

The ultimate goal which is something to strive for, is fulfilled when configuration, patching and applications are managed by a modern management solution, and there are no dependencies to on-premise resources such as ConfigMgr, distributions points, GPOs etc.

Do I believe this goal can be achieved regardless of organization and size? Yes. However, there are many challenges on the way and it will for sure not be easy nor quick for many organizations. For many organizations, it’s going to take years but for smaller organizations I see great possibilities to reach the goal on a much shorter period of time.

Applications

One of the biggest challenges in the modern world lies with applications. In the best of worlds, applications are moving away from using Kerberos or other traditional authentication mechanisms, as well as legacy code or runtime requirements. Instead rely on modern authentication and preferably OAuth 2.0, providing means to further remove dependencies to on-premise Active Directory at the same time enabling possibilities to use conditional access for instance.

Application strategy moving forward is a separate chapter and I will not cover that more in this blog post. I will solely focus on the deployment of the applications, as this is very much relevant in the various “co-management” scenarios.

Current applications, that is traditional and legacy applications packaged as MSI or in EXE format, needs to be replaced, reworked or repackaged. Today, repackaging can be done by repackaging to the AppX format. Popular packaging software like AdminStudio has had this capability for several years but if you want a free option look at Advanced Installer which also has the capability to package apps in the AppX format.

Regardless of the option you choose below for “co-management”, moving to this new packaging format is the way to move forward. At least for the option which is customers with no ConfigMgr, moving to this new package format is a requirement because there is no good way of deploying the applications unless you move to this new package format.

Note: MSIX is a new packaging format to come, as published on GitHub: MSIX Packaging recently, but for the moment AppX is the way to proceed until Microsoft eventually publish more information on MSIX.

Deployment Options

Customers without ConfigMgr

Option 1 (the only option for customers without ConfigMgr): Hybrid joined machines

(on-premise Active Directory joined + Azure AD registered/joined + GPO to set MDM auto enrollment)

If you do not use ConfigMgr, to activate “co-management” all you have to do is to make sure that your Windows 10 clients (1709 and later) are configured with the GPO setting to enable automatic MDM enrollment.

After that, start to move the GPO configuration over and add new configuration to MDM instead of using GPOs. Dismantle local infrastructure such as WSUS and start relying on Windows Update for Business. Also, look into AutoPilot.

Note: For hybrid joined machines it seems that Microsoft has not yet made (as of March 2018) it possible to be able to run PowerShell scripts via the Intune Management Extension. This is a very sad limitation because that means you have no way of deploying scripts for filling in the gap on current limitations of MDM, as you move to modern management.

Customers with ConfigMgr

Option 2: Hybrid joined machines (with Co-management in ConfigMgr unconfigured)

(on-premise Active Directory joined + Azure AD registered/joined + GPO to set MDM auto enrollment + ConfigMgr-agent installed via ConfigMgr)

This option mean you just connect your Windows 10 clients to your MDM solution with the GPO setting to enable automatic MDM enrollment, then stop doing what you are doing with GPOs and ConfigMgr today and instead do that in the MDM solution. This is the least effort option where you try to touch the ConfigMgr solution as little as possible and instantly just start the move away from ConfigMgr. This option is more suitable for smaller and rather simple ConfigMgr environments.

Option 3: Hybrid joined machines (with Co-management in ConfigMgr activated)

(on-premise Active Directory joined + Azure AD registered/joined + co-management activated in ConfigMgr + ConfigMgr-agent installed via ConfigMgr)

I suppose you can say that this is the true “co-management” in terms of what Microsoft would describe it as. This is the recommended way for most organizations that want to start the journey to modern management.

Option 4: Cloud joined machines (with Co-management in ConfigMgr activated)

(Azure AD joined + MDM joined + ConfigMgr-agent deployed via Intune)

Well this option is a good one but as the devices are not connected to an on-premise Active Directory, it requires that you have moved all GPOs and have managed to provide access to all on-premise resources for users when they are outside the company network. This option is more for future use, although this option might be good for some customers already.

Note: Even though devices are not connected to the on-premise Active Directory, they are able to use single sign on to access recourses on the internal network such as printers, network shares and other resources in the Active Directory domain. This is true as long as the device is on an internal network and has contact with an on-premise domain controller, where a Kerberos TGT is issued for accessing on-premise resources.

How to activate “co-management”

Option 1 and 2

For options 1 and 2 you configure your Windows devices and set the GPO “Enable automatic MDM enrollment using default Azure AD credentials” to Enabled. The GPO setting is located in Computer Configuration > (Policies) > Administrative Templates > Windows Components > MDM.

Option 3 and 4

The Microsoft Docs is the place to go to activate “co-management” in ConfigMgr. This includes the optional agent deployment via Intune.

Verify MDM connectivity and that your Windows clients are being “co-managed”

1. Dsregcmd command line

Run the following command to see if your devices are connected to Azure AD:

dsregcmd /status

The value for AzureAdJoined should read YES and MdmUrl should be set to for instance https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc

2. Modern control panel “Access work or school”

To check if the device has registered properly with the MDM tool you can also look in the modern control panel “Access work or school” (located in Accounts). Click any of the Windows logos or the briefcase and if you have the Info button you know that you have an active MDM enrollment for this device.

3. In the GUI of the MDM tool

Of course, the device should also pop up in your MDM solution and in Intune it will display as “MDM” is the device is Azure AD joined with MDM enrollment and it will show “MDM/ConfigMgr” if you are using ConfigMgr (or using option 1, that is not using ConfigMgr but still activating MDM enrollment for hybrid joined machines).

Troubleshooting

AzureAdJoined = NO

If AzureAdJoined is NO when you run “dsregcmd /status” then your devices have not registered with Azure AD which is required to be using “co-management”. Check the following:

1. Check Event Viewer and the log Applications and Services Logs > Microsoft > Windows > AAD > Operational. Optionally go to View and click Show Analytic and Debug Logs to get additional logs, and in AAD get the Analytic log which you must Enable before it will start logging.

No automatic MDM enrollment is made

If the MdmUrl is empty when you run “dsregcmd /status” and there is no “Info” button in Access work or school, then verify the following:

1. Make sure that you are using Windows 10 v1709 or later.
2. (Option 1 and 2) Verify that the GPO with MDM enrollment applies to the device.
3. (Option 3 and 4) Verify in the CoManagementHandler.log that CoManagementSettings_AutoEnroll equals True.
4. Verify that MDM automatic enrollment is configured in Azure AD, i.e. Azure Portal > Azure AD > Mobility (MDM and MAM). Also check that the user is covered by the MDM User Scope.
5. Verify that the user logging into the machine has an Azure AD Premium license assigned.
6. Check Event Viewer and the log Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Optionally go to View and click Show Analytic and Debug Logs to get additional logs, and in DeviceManagement-Enterprise-Diagnostics-Provider get the Debug log which you must Enable before it will start logging.

Just adding this quick blog post as there is nothing available on the Internet on this particular error, at least not what I could find or see at a first glance.  

UE-V problems in Windows 10 v1709 and looking in the Event log showed warnings events with ID 13008 and the text (for example): 

“Error 4 was returned while initializing sync provider for template MicrosoftInternetExplorer.Version11” 

As usual one of my favorite tools Process Monitor came to the rescue and quickly helped identify the problem: ACCESS DENIED when monitoring read/write access to the settings storage location. Turned out the owner of the folder was incorrectly set, adjusting that and everything got back to a working state.

This problem is interesting as it is not easily discoverable if you do not stare at the screen during the entire upgrade process, and hey, who does that? However, this is a very interesting finding when it comes to Windows as a Service that I am certain will affect many more enterprise customers (see cause section below).

Problem

Initiate an upgrade of Windows 10 to another version of Windows 10 using an inplace-upgrade task sequence via System Center Configuration Manager. The upgrade runs smooth until it reaches 75% (of the Upgrade step) where setup reboots the machine and then continue the last step of the upgrade, which is the migration phase. However, at 76% the user is presented with the login screen and the user thinks “well, the upgrade is done, let’s login!” after which the user login only to see a reboot a few minutes later, and also a rollback to the previous version of Windows.

The upgrade process is still running although the logon screen is presented, and when the user login, the migration engine of Windows setup shows a bunch of MIG errors due to files becoming locked. At the same time a rollback to the previous version of Windows 10 is initiated. The rollback by the way works very well! 

Cause

The cause of this issue is the software Net iD, which is a very common smart card application/credential provider for governments and others, providing smart card logon capabilities for all types of smart cards. When that piece of software is installed it somehow (still not determined exactly what is going on) interfere with the upgrade and the consequence is that the login screen is displayed although the upgrade continue in the background.

Workaround

Uninstall the Net iD client before doing inplace-upgrade to another Windows 10 version, and then install it as one of the last steps during the upgrade.

This is a follow-up blog post to my session yesterday at TechDays Sweden: “Windows 10 in new smart ways – not like you’ve always done it”. Thank you all who attended my session – it was a pleasure! The slides can be found here (in Swedish).

The link I mentioned about all news coming to MDM, and in particular new MDM settings are published at docs.microsoft.com.

And finally some resources to get you started with the move to modern IT – as I demoed in my session. Remember that the transition to a modern environment for managing devices will take time. As you lay a puzzle, lay out your path to modern management and IT one piece at a time!

AutoPilot – “hands-free deployment“

Desktop App Converter – Make AppX:s out of your MSI:s and legacy apps

“Co-management”
This basically mean that you can manage clients with SCCM and MDM at the same time. It’s branded as SCCM+MDM but you can also leverage this if you are not using MDM. So you can basically use and on-premise AD domain joined machine which is configured using GPOs and MDM join that machine to get MDM configuration at the same time. The idea is to make the move to modern management in a smooth way!

Windows Update for Business + Update Compliance
Transition from using WSUS (+SCCM) to manage updates and move to Update Compliance to follow up the status of patches, not quality updates and feature updates.

Device Health
Verify crashes for your Windows clients and more to come very soon!

Power BI – Intune Data Warehouse
Insights into how your users are actually accessing for instance Office 365 applications

Starting with Windows 10 Fall Creators Update Microsoft has revamped the OneDrive client and is now offering On-Demand synchronization of files. For those of you that remember we had the similar behavior in Windows 8.1 but this was changed for Windows 10.

There is a huge difference though in how OneDrive On-demand sync works in comparison to how it has been working in Windows 8 and 10 previously. OneDrive is now not just a part of the shell in Windows, it has integration with file system drivers from the kernel. This basically means that we do not face any compatibility issues with applications working with files in OneDrive as there is native Win32 support for accessing files in OneDrive.

So, with OneDrive On-Demand sync you have three states of the files (more about OneDrive On-Demand sync at the Windows blog). The Icons below marks that the files are downloaded and located on the machine.

Now, let’s look in the good old command prompt using the dir command to see the status of the above files. Nothing special with this, right?

But hey, the command attrib has been updated to adhere to the new features of OneDrive On-demand sync.

To pin a file (i.e. make it always available offline) use the command:

attrib +p -u Document2.docx

To unpin a file (i.e. make it available only in the cloud) use the command:

attrib -p +u Document1.docx

So, the end result in Windows File Explorer is as below. The cloud icon indicate that the file is only available in the cloud. The green circle with checkmark indicates that the file is always available offline.

Followed by this view in dir, i.e. note the parenthesis around the file which is available online only.

Pinning and unpinning multiple files and folders

To pin or unpin multiple files or folders, use the /s switch. To make all files and folders available recursively:

attrib +p -u /s

and to make all files and folders available in the cloud only:

attrib -p +u /s

Summary

To summarize with this new approach and the introduction of OneDrive On-demand sync you will have full application compatibility with OneDrive as well as the possibilities to aid users in controlling their OneDrive files state, or do inventory on it.

Many users want their start menu layout to be roamed, meaning they will get the start menu layout back when they reinstall their computer or log in to another computer. Starting with Windows 10 version 1703 Creators Update it is possible to roam the layout of the start menu using UE-V (User Experience Virtualization).

The start menu layout roaming with the UE-V template that I published over at the TechNet Gallery works best in scenarios where the devices have the same applications installed, otherwise the user will get shortcuts to applications that are not installed removed when clicking them.

NOTE: This is NOT an official solution and for sure an unsupported one. Let’s hope there will be a more supported solution from Microsoft in the future.

Download the UE-V template for start menu roaming in Windows 10 v1703 or later

When you have activated Credential Guard for Windows 10 (1607), you might note errors on your clients when they try to update group policies:

Windows failed to apply the {F312195E-3D9D-447A-A3F5-08DFFA24735E} settings.

You will also find thw below error in the DeviceGuard Operational event log:

Device Guard failed to process the Group Policy to enable Virtualization Based Security (Status = 0x80070057): Invalid parameter

The problem seems to be related to the incorrect registry value HypervisorEnforcedCodeIntegrity being written. It’s set to 3 on Windows 10 v1607, which seems to be a totally undocumented and invalid value. Verify under the key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard. This value is written as long as the setting “Virtualization Based Protection of Code Integrity” found in the GPO setting “Turn on Virtualization Based Security” is set to “Not configured”.

Solution

In the GPO setting Turn on Virtualization Based Security found in Computer Configuration\Administrative Templates\System\Device Guard edit the and set Virtualization Based Protection of Code Integrity to Disabled. This will make the HypervisorEnforcedCodeIntegrity turn to 0 and the GPO will apply without errors.

Ever wondered why the search feature in Windows 10 list the results as it does? Today I found a really interesting text file that shed more light on how some search results are listed.

One of my favorite tools in Windows is “Resource Monitor“. I use it all the time, basically every day to figure out what is going on in Windows, most of the times at the disk activity tab and watching what is going on (if things are installing, if something is being downloaded or what log files things are written to etc).

What I found today made me laugh and smile for quite some time. I found a text file containing app synonyms, and in there lies some explanation to why and how the search feature in Windows 10 lists search results as it does when searching for applications, apps and settings.

The funny thing is that it lists all common misspelling of some common applications. For instance, did you know that you can do a search for “exell” and it will display “Excel 2016” in the search results? You can also type “npo” to find “Notepad“, or type “c prompt” that will list “command prompt”, or “exx” that will find “Internet Explorer” or if you search for “ie” and it will list “Edge”.

The file where all these synonyms are gathered is named appssynonyms.txt and is located in C:\Users\%username%\AppData\Local\Packages\ Microsoft.Windows.Cortana_cw5n1h2txyewy\LocalState\ ConstraintIndex\Input_{3fe4e30f-3de5-44d2-b081-e763cc324698}

This is just hilarious, and it made my day 😊 Now I know another reason why Microsoft need to collect whatever the user types (when telemetry is set to “full”); To gather more misspellings and intel for this synonyms list.

Note: Also see settingssynonyms.txt in the same directory as the one above, where all aliases for finding control panels and settings are listed!

There are new WMI classes in Windows 10 that can be used to collect software inventory. The information can be displayed using PowerShell. Also, there is a feature that inventories what framework or runtime an application is dependent on, for instance which version of .NET Framework or Visual C++ Runtime and it can even see if there are dependencies for OpenSSL. Imagine having these feature in place when the HeartBleed bug appeared a few years ago.

Display all installed applications on a Windows 10 machine:

Get-WMIObject Win32_Installedwin32Program | select Name, Version, ProgramID | out-GridView

Display all apps and dependent frameworks on a Windows 10 machine for a specific application (replace the ProgramID in the filter section with another one from the above example), and make sure everything is on one row:

Get-WMIObject Win32_InstalledProgramFramework -Filter "ProgramID = '00000b9c648fd31856f33503b3647b005e740000ffff'" | select ProgramID, FrameworkName, FrameworkVersion | out-GridView

or to bake them together to get both the application name and associated frameworks:

$Programs = Get-WMIObject Win32_InstalledWin32Program | select Name,ProgramID
$result = foreach ($Program in $Programs) {
$ProgramID = $program.programID
$Name = $program.Name
$FMapp = Get-WMIObject Win32_InstalledProgramFramework -Filter "ProgramID = '$programID'"
foreach ($FM in $FMapp) {
$out = new-object psobject
$out | add-member noteproperty Name $name
$out | add-member noteproperty ProgramID $ProgramID
$out | add-member noteproperty FrameworkPublisher $FM.FrameworkPublisher
$out | add-member noteproperty FrameworkName $FM.FrameworkName
$out | add-member noteproperty FrameworkVersion $FM.FrameworkVersion
$out
}
}
$result | out-gridView

Now, happy hunting for runtime dependencies!

Those of you who know me know that I am somewhat stubborn and I never give up. This case could easily have gotten anyone to crack! This blog post shows a way to restore favorites from within a UE-V (User Experience Virtualization) package that UE-V cannot use to roam the favorites, as the package is considered invalid.

Problem

A user has created some 2346(!) favorites in Internet Explorer over the years. UE-V is used to roam favorites. After the user reinstalled the machine from Windows 7 to Windows 10, the favorites went missing.

Investigation

To start with, the package supposedly containing the favorites (MicrosoftInternetExplorer.common.pkgx) could still be found in the SettingsPackages folder and the size was 1,24MB and dated just a week ago. Those of you that have worked with UE-V know that a package that large signals that it contains a rather large amount data. Therefore, with that indication I assumed that the favorites is still lurking in there.

First thing to try was to just force the read of the package using via the UE-V agent as is the case whenever IE is started or closed, however Event Viewer revealed that UE-V thinks there is some kind of problem with the package.

The initial settings package for settings location template "MicrosoftInternetExplorer.common" is invalid. The initial settings package will be replaced with a new copy.

Now it is time to analyze the package itself. Note: This took quite some time to process by the cmdlet and it seems that the UE-V agents takes the same amount of time to process this large amount of favorites (~30 seconds).

Export-UevPackage c:\temp\MicrosoftInternetExplorer.common.pkgx | out-file C:\temp\ MicrosoftInternetExplorer.common.txt

Reading the output text file revealed that the user had 2346 favorites, data in the following format:

<SettingsDocument>
<file>
<Setting Type="VT_FILE" Name="file://{1777F761-68AD-4D8A-87BD-30B759FA33DD}\Folder1\Name of site 1.url" Action="Update">FEBB399A-8DF5-4B3D-B73D-A8167F61EB6B.pkgdat</Setting>
<Setting Type="VT_FILE" Name="file://{1777F761-68AD-4D8A-87BD-30B759FA33DD}\Folder1\Name of site 2.url" Action="Update">9FA223F9-F065-4269-B02C-E467A6B26459.pkgdat</Setting>
<Setting Type="VT_FILE" Name="file://{1777F761-68AD-4D8A-87BD-30B759FA33DD}\Folder2\Name of site 3.url" Action="Update">2393C0D8-AEDE-4D11-9CE3-E7E1E4B039CA.pkgdat</Setting>
...
…

Next up, rename the MicrosoftInternetExplorer.common.pkgx to MicrosoftInternetExplorer.common.zip and open it up. Note that you probably also would want to unblock the ZIP file before extracting the contents, choosing Properties and Unblock. Opening the PKGX as a ZIP shows us all the PKGDAT files listed in the output from Export-UevPackage. Extract the PKGDAT files to a folder, in my example c:\Temp\PKGDAT.

With these data sources, we have everything we need to recreate the URLs and their structure. Basically, what we need from the output from Export-UevPackage is the folder where the URL file is stored, the name of the URL file and the name of the PKGDAT filename.

Solution

With the aforementioned pieces of data, we can automate and match this to rebuild the Favorites entirely, using this PowerShell script:

$urls = (Export-UevPackage c:\temp\MicrosoftInternetExplorer.common.pkgx).split(“`n”) | select-string VT_FILE

foreach ($extracted in $urls)
{

$hash1 = $extracted -split ‘<Setting Type=|Name=|Action=|</Setting>’
$folder = $hash1[2].split(“\”)[1]
$urlname = $hash1[2].split(“\”)[-1].Replace(‘”‘,“”)
$pkgdat= $hash1[3].Split(“>”)[1]

New-Item c:\temp\RestoredURLs\$folder -type directory

if ($folder -match ‘”‘)
{
Copy-Item c:\temp\PKGDAT\$pkgdat c:\temp\RestoredURLs\$urlname
} else {
Copy-Item c:\temp\PKGDAT\$pkgdat c:\temp\RestoredURLs\$folder\$urlname
}
}

This recreated the favorites and in the same structure as it was! The user was indeed very happy!

Thanks goes to my colleague Jimmy Benandex who helped in making the above PowerShell command. As he mentioned there are better ways of doing the matching but I consider what we produced as a good enough solution :)