Conditional access and Windows 7 domain joined devices

This week is all about conditional access in combination with Windows 7 domain joined devices. I know, simple solution, migrate as fast as possible to Windows 10. Having said that, it’s not always possible to simply migrate those devices to Windows 10 and in the mean time those devices do need access to Office 365. That’s why I thought it would be good to write something about those Windows 7 domain joined devices in combination with conditional access. As Windows 7 should not be a reason to not implement conditional access. In this post I’ll provide the details about the additional configurations that need to be in place, to allow Windows 7 domain joined devices access to Office 365. So, not directly about conditional access, but about the configurations that must be in place.


Before looking at the configuration, let’s start with a list of prerequisites that need to be in place. These are the general configurations that also need to be in place for Windows 10. Also, the configurations are nowadays triggered and/or mentioned during the installation of Azure AD Connect.

  • Configure service connection point – The service connection point (SCP) object is used by devices, during the registration, to discover Azure AD tenant information;
  • Setup issuance of claims – In a federated Azure AD configuration, devices rely on AD FS to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).


Now let’s continue with the configurations specific to Windows 7, and other down-level operating systems. Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2, are considered down-level operating systems. Down-level operating systems require the following additional configurations:

  1. Configure Azure AD to enable users to register devices;
  2. Configure on-premises AD FS  to issue claims to support Integrated Windows Authentication;
  3. Add Azure AD device authentication end-point to the local Intranet zones;
  4. Install the Microsoft Workplace Join for non-Windows 10 computers package.

Configuration 1: Configure Azure AD

The first configuration, that must be in place, is that users must be enabled to register devices in Azure AD. The following 2 steps walk through that configuration. When using enrollment with Microsoft Intune, or MDM for Office 365, this configuration will be in place automatically.

1 Open the Azure portal and navigate to Azure Active Directory > Devices > Device settings to open the Device  Device settings blade;
2 On the Device – Device settings blade, select All with Users may register their devices with Azure AD and click Save;


Configuration 2: Configure on-premises AD FS

Before starting with the second configuration, it’s good to mention that it’s no longer required to have an on-premises AD FS to register domain joined computers with Azure AD. Having mentioned that, the second configuration, that must be in place, when using AD FS, is that the on-premises AD FS must support issuing the authenticationmehod and wiaormultiauthn claims when receiving an authentication request to the Office 365 relying party trust. This can be achieved by adding an issuance transform rule that passes-through the authentication method. The following 5 steps walk through that configuration by using AD FS 4.0 (Windows Server 2016).

1 Open the AD FS Management console and navigate to AD FS > Relying Party Trusts;
2 Right-click the Microsoft Office 365 Identity Platform relying party trust and select Edit Claim Issuance Policy;
3 On the Issuance Transform Rules tab, select Add Rule to open the Add Transform Claim Rule Wizard;
4 On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next;

W7_CustomClaimOn the Configure Claim Rule page, provide the following information and click Finish;

  • Claim rule name: Auth Method Claim Rule;
  • Claim rule: c:[Type == “”] => issue(claim = c);

To finish the AD FS configuration, run the following PowerShell command to allow IWA, or MFA, for the Office 365 relying party trust.

Set-AdfsRelyingPartyTrust -TargetName “Microsoft Office 365 Identity Platform” -AllowedAuthenticationClassReferences wiaormultiauthn

Configuration 3: Add end-points to local intranet zones

The third configuration, that must be in place, is that the Azure AD device authentication end-point must be added to the local intranet zones. That should avoid certificate prompts. In my case the device registration would even fail, with a clear error in the Event Viewer (Event ID: 406). That event literally provides the solution of adding the URL to the local intranet zone. The following 6 steps walk through the configuration by assuming that an existing policy is available.

1 Open the Group Policy Management console and navigate to Group Policy Management > Forest > Domains;
2 Right-click an existing GPO and select Edit;
3 In the Group Policy Management Editor, navigate to Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page;
4 Right-click Site to Zone Assignment List and select Edit;
5 In the Site to Zone Assignment List dialog box, select Enabled and click Show;

W7_ShowContentsIn the Show Contents dialog box, provide the following information and click OK in the open dialog boxes;

  • Value name:
  • Value: 1

Note: In my case I also still had to add my identity provider to the local intranet zone (which is value 1).

Configuration 4: Install Microsoft Workplace Join for non-Windows 10 computers

The fourth configuration, that must be in place, is the installation of the Microsoft Workplace Join for non-Windows 10 computers package. The installation of that package creates a scheduled task on the system that runs in the user’s context. The task is triggered when the user signs in to Windows and silently registers the device with Azure AD.

The following 7 steps walk through the simple creation of an application, for the Microsoft Workplace Join for non-Windows 10 computers package, in Configuration Manager. That application can then be deployed to the required devices. Before starting with the steps below, make sure to download the Microsoft Workplace join for non-Windows 10 computers package.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Application Management > Applications;
2 Click Create Application to open the Create Application Wizard;
3 On the General page, provide the name and location of the MSI and click Next;
4 On the Import Information page, click Next;

W7_CAWOn the General Information page, provide at least the following information and click Next;

  • Name: Microsoft Workplace Join for Windows;
  • Installation program: msiexec /i “Workplace_x64.msi” /q
  • Install behavior: Install for system
6 On the Summary page, click Next;
7 On the Completion page, click Close;


Let’s end this post by looking at the configuration results. The result should be that the Windows 7 domain joined devices are registered to Azure AD. The first place to look for a success is the Event Viewer. Open the Event Viewer and navigate to Applications and Services Logs > Microsoft-Workplace Join. As shown below, for a successful device registration this log should show Event ID 201 (Workplace join operation succeeded).


The second place to look for a success is PowerShell. Simply use the Get-MsolDevice cmdlet. Below is an example of 1 of my devices, which clearly shows the version of the operating system and Domain Joined trust type.


The third place to look for a success, and last place that I’ll show, is the Azure portal. Now simply navigate to Azure Active Directory > Devices > All devices. Below is and example, in which I selected 1 of my devices, which clearly shows the version of the operating system and the Hybrid Azure AD joined join type.


Once the Windows 7 domain joined device is successfully registered with Azure AD, the device can be granted access to Office 365 by using the access control of Require domain joined (Hybrid Azure AD) in conditional access.

More information

For more information about Windows 7 and conditional access, refer to the following articles:

How to apply the default install.wim of Windows 7 to C:\ with ConfigMgr 2012

It’s already known that the default install.wim of Windows 8, by default, applies to C:\, but wouldn’t it be great if there was this same functionality for Windows 7? That way there is no need for a Build and Capture task sequence anymore to maintain a thin image. Applying the default image to C:\ in combination with offline servicing of updates will do the trick. Well… I’ve got good news! In this post I will show how to apply the default install.wim of Windows 7 to C:\!


TSEdiOSDPreDriLetThe configuration is actually very easy, it’s more about knowing that it exists. ConfigMgr 2012 SP1, which is currently still in BETA, brings a set of new task sequence variables. One of these variables can be used to apply the install.wim to any drive of choice. To configure this, follow the next steps:

  • Open a task sequence, to deploy Windows 7, in the Task Sequence Editor.
  • Add a Set Task Sequence Variable –step anywhere before the Apply Operating System –step.
  • Fill in as Task Sequence Variable OSDPreserveDriveLetter and as Value False.
  • Close the Task Sequence Editor.


By default the install.wim of Windows 7 would have applied to D:\, but by setting OSDPreserveDriveLetter to False it will apply to any drive of choice. Of course I can show this result with a screenshot of an Windows Explorer, but I think, in this case, a look at the SMSTS.log file will show more information of this success.OSDPreDriLet

Migrating to Windows 8 by using hard-links with ConfigMgr 2012

After the release of Windows 8 last week we can already start thinking about migrating. When I’m thinking about migrations I always like the computer-refresh scenario’s where we can use hard-links. In this post I will show a basic task sequence to capture user files and settings, either offline or online, with help of hard-links. I already showed the basics of that in an earlier post last year when ConfigMgr 2012 was still in Beta. Since then the Wizard screens have not changed so I will not show that again, but  I will show some more information about what happens.


To support migrating to Windows 8 we need ConfigMgr 2012 SP1 (which is currently still CTP) in place with at least the following packages:

  • Boot Image package, of at least version 6.2.xxxx
  • ConfigMgr client package
  • USMT 5.0 package, of at least version 6.2.xxxx
  • Image package, which can be the default install.wim of Windows 8

Basic steps

To create a task sequence that can migrate to Windows 8 we can use the following steps (for screenshot see my earlier post of last year):

  • Right-click the Task Sequence node and select Create Task Sequence.
  • On the Create a New Task Sequence page, select Install an existing image package and click Next.
  • On the Task Sequence Information page, fill in a Task sequence name, Browse for the Boot image and click Next.
  • On the Install Windows page, browse for the Image package, uncheck Partition and format the target computer before installing the operating system, (optional) uncheck Configure task sequence for use with Bitlocker, (optional) fill in a Product key, (optional) select Always use the same administrator password and click Next.
  • On the Configure Network page, (optional) select Join a domain, Browse for the Domain and Domain OU, Set an Account and click Next.
  • On the Install ConfigMgr page, Browse for the ConfigMgr client Package, (optional) fill in the Installation Properties and click Next.
  • On the State Migration page, select Capture user settings, Browse for the USMT Package, select Save user settings locally, (optional) uncheck Capture network settings, (optional) uncheck Capture Microsoft Windows settings and click Next.
  • On the Install Updates page, click Next.
  • On the Install Applications page, click Next.
  • On the Summary page, click Next.
  • On the Progress page, just wait…
  • On the Confirmation page, click Close.

Advanced steps

The basic steps will create a task sequence that will only perform it’s capture while the task sequence is running online (Full OS). Also notice that the task sequence already sets the ‘extra’ task sequence variable OSDStateStorePath to the value %_SMSTSUserStatePath%. But when we also want to be able to perform an capture while the task sequence is running offline (WinPE), we need to make the following small adjustments.

  • TSEd_RemConSelect the Capture Files and Settings Group, go to the Options tab and Remove the Conditions (or remove the whole top Group).

    Explanation: This is necessary to make it possible to also capture user files and settings in WinPE.

  • Select the Capture User Files and Settings Step (optional: change the name), go to the Options tab and add the condition of _SMSTSInWinPE equals FALSE.

    TSEd_FullOSExplanation: This is necessary to make this step only run in FullOS. This step will run the following scanstate command: C:\_SMSTaskSequence\Packages\<ID>\amd64\scanstate.exe C:\_SMSTaskSequence\UserState /o /localonly /efs:copyraw /c /hardlink /nocompress /l:C:\Windows\CCM\Logs\SMSTSLog\scanstate.log /progress:C:\Windows\CCM\Logs\SMSTSLog\scanstateprogress.log /i:C:\_SMSTaskSequence\Packages\<ID>\amd64\migdocs.xml /i:C:\_SMSTaskSequence\Packages\<ID>\amd64\migapp.xml

  • TSEd_WinPEAdd an extra Capture User State Step (optional: change the name), select Copy by using file system access and check Continue if some files cannot be captured, Capture locally by using links instead of copying files and Capture in off-line mode (Windows PE only). Now go to the Options tab and add the condition of _SMSTSInWinPE equals TRUE.

    Explanation: This is necessary to make this step only run in WinPE.This step will run the following scanstate command: C:\_SMSTaskSequence\Packages\<ID>\amd64\scanstate.exe C:\_SMSTaskSequence\UserState /o /localonly /efs:copyraw /offlineWinDir:C:\WINDOWS /c /hardlink /nocompress /l:X:\WINDOWS\TEMP\SMSTSLog\scanstate.log /progress:X:\WINDOWS\TEMP\SMSTSLog\scanstateprogress.log /i:C:\_SMSTaskSequence\Packages\<ID>\amd64\migdocs.xml /i:C:\_SMSTaskSequence\Packages\<ID>\amd64\migapp.xml

  • TSEd_RestTo complete the overview, I’ll show here the default values of the restore settings. (Optional) Select Restore local computer user profiles and give in a password.

    Explanation: This step will run the following loadstate command: C:\_SMSTaskSequence\Packages\<ID>\amd64\loadstate.exe C:\_SMSTaskSequence\UserState /ue:<computername>\* /c /hardlink /nocompress /l:C:\WINDOWS\CCM\Logs\SMSTSLog\loadstate.log /progress:C:\WINDOWS\CCM\Logs\SMSTSLog\loadstateprogress.log /i:C:\_SMSTaskSequence\Packages\<ID>\amd64\migdocs.xml /i:C:\_SMSTaskSequence\Packages\<ID>\amd64\migapp.xml

I still remember creating all batch files to perform these actions. Now they are possible out of the box!


Now running this task sequence from either Full OS or WinPE will result in something like the example under here. In this example I migrated some files, folders and background. This last one will show as first in the new Windows 8 machine.

Before After
Before After

Installing and enabling Remote Server Administration Tools with ConfigMgr 2007

It took me a while to figure out something that is actually very simple and logical… I couldn’t get the different parts of the Remote Server Administration Tools (RSAT) enabled by command-line on Windows 7 x64… On Windows 7 x86 it’s pretty straight forward, as it can be done with the default DISM commands. But on Windows 7 x64 it is kind of hard to get it to use the correct version of DISM.

ConfigMgrClientThis is all because the ConfigMgr client is 32-bit application and whenever a 32-bit application wants to access %windir%\System32, it will be redirected to %windir%\SysWOW64. I tried everything, even specifying the whole path to the DISM executable, but it all didn’t matter… Until I finally figured out that there is just something called SysNative. WOW64 recognizes SysNative as a special alias used to indicate that the file system should not redirect the access. As it was kind of hard to find this information I will post my solution here to install RSAT and enable some features. This is the batch-file I ended up:

REM ======================================================
REM SET DISM Directory based on OS Architecture
REM SET RSAT Version based on OS Architecture
REM ======================================================

IF EXIST %WINDIR%\SysNative\dism.exe (
    set DISM=%WINDIR%\SysNative\dism.exe
    set RSAT=amd64fre_GRMRSATX_MSU
) ELSE (
    set DISM=%WINDIR%\System32\dism.exe
    set RSAT=x86fre_GRMRSAT_MSU

REM ======================================================
REM RUN WUSA to install RSAT
REM ======================================================
wusa.exe %~dp0%RSAT%.msu /quiet

REM ======================================================
REM RUN DISM to enable features
REM ======================================================

%DISM% /online /enable-feature /featurename:RemoteServerAdministrationTools
/featurename:RemoteServerAdministrationTools-Roles-HyperV /quiet

REM ======================================================
REM EXIT Errorlevel
REM ======================================================

EXIT /b %errorlevel%

The first part of the batch-file set the variables based on the architecture and the second part will do the actual installing and enabling (in the example it will enable the Hyper-V manager). To conclude this story, follow the next five steps to install and enable Remote Server Administration Tools with ConfigMgr 2007:

  1. Download the full installer(s) of Remote Server Administration Tools (amd64fre_GRMRSATX_MSU.msu and/ or x86fre_GRMRSAT_MSU.msu) here:
  2. Copy the code above and create a batch-file.
  3. Create a new Package in ConfigMgr 2007 (Site Database > Computer Management > Software Distribution > Packages) and point the Data Source to the location where the installer(s) and the batch-file are.
  4. Create a new Program with the newly created package and use as command-line the name of the, just created, batch file.
  5. Create a new Advertisement of the newly created program and it is all ready to install and enable!

More information about File System Redirector:

ConfigMgr 2007, Updating a Windows 7 Image with the latest Software Updates – A less conventional, but very effective way

Inspired by a previous post about the option to Schedule Updates for an already existing Operating System Image in ConfigMgr vNext, I created a little batch-file to do something similar without the GUI of ConfigMgr vNext. Of course, I do know that the ‘best practice’ for ConfigMgr 2007 is to just run another Build and Capture Task Sequence, but in some cases this can come in handy. One thing is for sure, this updates a Windows 7 Image within fifteen minutes.

Background Story

Now lets start with a little background story, to explain why in some situations there might be the need for this batch-file. Every month there are new Software Updates released by Microsoft. During the Software Updates Deployment the, for the organization needed, updates get selected and downloaded to the Software Update Package. In other words, the, for the organization needed, updates are already downloaded and available. To update the existing image with the newest updates, the ‘best practice’ is to deploy the newest updates and run another Build and Capture Task Sequence. Sometimes, especially at smaller companies, this is considered as a lot of extra work/ effort and because of that, it is often forgotten. Even though an up-to-date Windows 7 Image deploys a lot faster then a Windows 7 Image that still has to install a lot of Software Updates. So to help out the people that are just to busy (you can actually fill in anything you want, I just like to think that they are to busy), I created this batch-file that will do everything.PckgSrcLctn

Input Locations

Well… after this all being said, lets take a look at the two most important inputs that we need for this batch-file:

  1. The current setup of the batch-file assumes that there is a  Software Updates Package for all Windows 7 (x86 and x64) updates. The Package source of this package is used as input for this batch-file. This location can be found in the Properties of the Software Updates Package (see the first picture) in the ConfigMgr Console. By doing this, it is not needed to re-download the Software Updates, it’s only needed to gather the Software Updates together from all the subdirectories.
  2. Another important input for the batch-file is the location of the Windows 7 Image, which has to be updated. For this the Image path can be used, which can be found in the Properties of the Operating System Image (see the second picture) in the ConfigMgr Console. Don’t forget that it is still needed to update the Distribution Point(s) after the batch-file has run!


As we know now a little background story and we know where the most important parts of the input comes from, lets take a look at the batch-file that will make it happen.

REM =========================================
REM ARGUMENT -1- TempPartition = %1
REM ARGUMENT -2- UpdatesPackageSource = %2
REM ARGUMENT -3- Architecture = %3
REM ARGUMENT -4- WimFileAndLocation = %4
REM ===================================================

REM ===================================================
REM Make (temporary) directories for updates and mounting
REM ===================================================

MD %1\TEMP\Mount
MD %1\TEMP\Updates

REM ======================================================
REM Copy new updates of %3 -architecture and of > %5 -date to temporary directory
REM ======================================================

FOR /R %2 %%P IN (* DO (
XCOPY "%%P" %1\TEMP\Updates /H /C /Y /D:%5

REM ======================================================
REM Mount image, add updates, commit and unmount
REM ======================================================

DISM /Mount-Wim /WimFile:%4 /Index:1 /MountDir:%1\TEMP\Mount /LogPath:%1\DISM.Log
DISM /Image:%1\TEMP\Mount /Add-Package /PackagePath:%1\TEMP\Updates /LogPath:%1\DISM.log
DISM /Unmount-Wim /MountDir:%1\TEMP\Mount /Commit /LogPath:%1\DISM.log

REM ======================================================
REM Remove (temporary) directories again
REM ======================================================

RD %1\TEMP /S /Q

The biggest part will explain itself, with or without the comments, but it also shows here that I am using five variables. This is to make it easier adjustable for different Windows 7 Images, Package source location, architectures and dates. These variables are used in the following way:

  1. %1 – Presents the volume that can be used to store the temporary folders.
  2. %2 – Presents the full location of the Software Updates Package source.
  3. %3 – Presents the architecture of the Operating System.
  4. %4 – Presents the full location of the Operating System Image, including the name of it.
  5. %5 – Presents the date of the oldest Software Updates that have to be added (Format: MM-DD-YYYY).

Now lets end this post with how to run this batch-file:
[NameOfBatchFile].BAT [DriveLetter:] [SoftwareUpdatesPackageSourceLocation] [Architecture] [WIMLocation\WIMName] [DateLatestNeededUpdates]

User Driven OS Deployment with “Modena”

It took a while but this weekend it was finally time for some testing of, what’s code-named, “Modena”. Modena is a tool, developed by Microsoft IT, that enables the ability of an End-User Experience by using a powerful OSD Wizard.

ModWelcWhen you are searching for a way to get your users “involved” in an OS Deployment, then I would recommend you to take a look at Modena. The OSD Wizard of Modena (see picture) can be changed in a lot of different way’s. As an administrator you can select which settings can be done by a user and which are pre-set. By these customizable settings you can think about things like computername, domain, local administrators, language, time, image, backup (via USMT 4.0) and the applications. The nice thing about the applications is that you can first do a scan of the computer to see what applications are currently installed. Based on the results of this scan, applications can get pre-selected (or not). Besides al of these settings Modena also provides a better insight in what is happening with the computer during the Task Sequence.

To make a long story short, take a look at Microsoft Connect to get Modena: 
>> <<

Also take a look at the following links for setting up Modena…
1. Getting started with Modena – Step 1 – Installing Modena:
2. Getting started with Modena – Step 2 – Create OSD Packages:
3. Getting started with Modena – Step 3 – Importing Task Sequences:
4. Getting started with Modena – Step 4 –Introduction to OSD Designer:
5. Getting started with Modena – Step 5 – Using Modena Online Services:
6. Getting started with Modena – Step 6 – Setting Up Applications:

…and take a look at these links for the story behind Modena.
General Cravings of OSD:
Windows 7 Deployment Guide:

Error trying to open the ConfigMgr Console

Last week I had some problems with opening the ConfigMgr Console. The weird part was that the error only appeared for one user. This was the error I got: MMC cannot open the file <driver>:\Program Files (x86)\Microsoft Configuration Manager\AdminUI\bin\adminconsole.msc. This may be because the file does not excist, is not an MMC console, or was created by a later version of MMC. This may also be because you do not have sufficient rights to the file.

Then I figured that, because the ConfigMgr Console is a MMC snap-in, it creates a version in the user profile. Because I use Windows 7 and Windows Server 2008 R2 it is located at: <Drive>:\Users\<Username>\AppData\Roaming\Microsoft\MMC\adminconsole.msc.

So after deleting the version from the profile and restarting the ConfigMgr Console it all worked like a charm.

Configuration Manager 2007 SP2 RC has been released

Today a little newsflash from the System Center Configuration Manager team.

The System Center Configuration Manager team would like to announce that the following has been released and available for download: Configuration Manager 2007 Service Pack 2 Release Candidate.

This is the official Release Candidate build for Configuration Manager 2007 SP2.

New features:

  • Refer to the SP2 Overview article posted on the primary Configuration Manager MSConnect site for all the new features and new supported configurations.
  • Hotfixes included in SP2 article can be found on the primary Configuration Manager MSConnect page.
  • Deployment guides for BranchCache and the new AMT features are available in the download section.
  • The new OpsMgr07 R2 ConfigMgr07 Management Pack can also be downloaded, this supports 64bit OpsMgr client agents.
  • Please review the Release Notes before performing any installation and upgrade.

Feedback and Support:

  • All registered Sp2 Open Beta users can submit bugs, design change requests (DCR’s), and other feedback. See the help link on the ConfigMgr MSConnect homepage for more instructions.
  • Newsgroups are a great way to post questions and receive general support question answers.

If you experience any issues with the download or the MSConnect site please contact,

The Configuration Manager Customer Team

App-V future ready???

Let’s start my first post about App-V being future ready (or not). When I was trying to deploy an App-V Sequence on a Windows 7 Client (with App-V Client 4.5 CU1) the application didn’t seem to work… At first I thouhgt it was just me, so I recreated everything from scratch, but still no luck. The next step was to search on Google and here I found a very helpfull link:

The solution is this: During the proces of making a sequence with the App-V Sequencer you get to tab Deployment. In this tab you can specify the Operating System (OS) on which this sequence can run. Before the App-V 4.5 CU1 version you didn’t have the option to select Windows 7. This means that the sequence will not be able to run on Windows 7. The sequence can only run on the OS that is selected on the Deployment tab (it is possible to change the OS directly in the OSD-file, for this you have to add an extra line like: <OS VALUE=”Win7″>).

After all this you can say that App-V is future ready, because by adding Windows 7 to the Deployment tab it was possible to deploy the sequence on Windows 7. Just a shame that you have to make changes to already excisting sequences…