Notes From The Field, Volume 1 – The Hybrid AD Device Management Troubleshooting Guide

I always have a rule of thumb “if it takes more than an hour to solve, it deserves sharing”, and that’s always been the story of my blogs over the last decade plus. The biggest struggle is finding the time to sit down, pull all my notes together, and sharing it with the larger IT community. With a holiday weekend and time off, since I’m not WORKING working, I figured why not start a fun series in the Microsoft Modern Workplace space I spend most of my time architecting, deploying & speaking about!

Volume 1 will cover a topic that has been near and dear (and a pain in my rear) to me, and it has to do with the Microsoft Device Management story as it pertains to Hybrid AD devices. Azure AD is the nirvana, mountain top goal that all organizations should be aiming, but as a realist in recognizing that takes time, time, and more time, starting off with Cloud management is a baby step in bringing the rest of an organization.

To meet the prerequisites for the SCCM Co-Management story, Hybrid AD and Intune registered devices for MDM are necessary; see:

In a Hybrid AD scenario this requires line of sight to a domain controller (which also applies to AutoPilot and Hybrid AD, but that’s for another Volume), but what happens with a remote workforce? Let’s dig into the “gotchas” to bring these devices into the fold.

Continue reading “Notes From The Field, Volume 1 – The Hybrid AD Device Management Troubleshooting Guide” »

Where Hast Thou Gone, Workplacejoin.exe?

In looking to help a customer Azure AD join downlevel Windows 7 devices to their tenant, Microsoft has broken the download link (go ahead, try it yourself)


Thankfully a colleague of mine has been working on a project and had those executables for 32 and 64 bit on their network. So I’ve got them ZIP’d up and on my server here. Enjoy!


Journey in Hybrid Cloud Print

I don’t take the term “journey” lightly because now a month in I’m edging closer and closer to the finish but I still feel like I have a long way to go. From lots of reading and even some advise to “abandon the idea”, I’m not one to be a quitter

Thought I’d decide to give it a shot, but definitely fell short with the Microsoft documentation given all of the intricacies of the deployment:

Thanks to Sandy’s blog post I certainly got closer, even took the effort to build out an deployment Powershell script (which you can find here on my GitHub), and the server side portions are definitely getting further than ever. My final steps are shoring up the Intune policy in my lab and then the Windows 10 printer setup (which I hear is the final hurdle to the mountain top)

But when I took the script to run in my client’s production environment, I was missing files in the MophiaPrint folder in the inetpub\wwwroot directory, as well as the EnterpriseCloudPrint virtual directory:


But in my lab:


See? Both the EnterpriseCloudPrint and MopriaCloudService are there, which is evident by the EnterpriseCloudPrint virtual directory

Of course my first thing to do was crack open the Powershell script for installation

cd ‘C:\Program Files\WindowsPowerShell\Modules\PublishCloudPrinter\’
notepad .\CloudPrintDeploy.ps1

Then I looked at the lines of code

Write-Output “** Deploying Enterprise Cloud Print binaries”
“** Installing Enterprise Cloud Print binaries” | Out-File $LogFile -append
dism /online /Add-Capability /CapabilityName:Print.EnterpriseCloudPrint~~~~ >> $LogFile
Write-Output “** Deploying Mopria Discovery Service binaries”
“** Installing Mopria Discovery Service binaries” | Out-File $LogFile -append
dism /online /Add-Capability /CapabilityName:Print.MopriaCloudService~~~~ >> $LogFile

In said CloudPrintDeploy.log

** Installing Enterprise Cloud Print binaries

Deployment Image Servicing and Management tool
Version: 10.0.14393.0

Image Version: 10.0.14393.2457

Error: 87

No Windows features were specified on the command line.
Use the /Get-Features option to find the name of the feature in the image and try the command again.

The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
** Installing Mopria Discovery Service binaries

Deployment Image Servicing and Management tool
Version: 10.0.14393.0

Image Version: 10.0.14393.2457

Error: 87

No Windows features were specified on the command line.
Use the /Get-Features option to find the name of the feature in the image and try the command again.

So I try to run the dism command outside of Powershell. Duh, same result.

So I found the command DISM /online /get-capabilities to see what capabilities were available for this build on the client server

DISM /online /get-capabilities

Deployment Image Servicing and Management tool
Version: 10.0.14393.0

Image Version: 10.0.14393.2457

Capability listing:

Capability Identity : Language.Basic~~~en-GB~
State : Installed

Capability Identity : Language.Basic~~~en-US~
State : Installed

Capability Identity : Language.Handwriting~~~en-US~
State : Installed

Capability Identity : Language.OCR~~~en-US~
State : Installed

Capability Identity : Language.Speech~~~en-US~
State : Installed

Capability Identity : Language.TextToSpeech~~~en-US~
State : Installed

But when I go to run the same on my regular 14393 build, I get a TON more features….

PS C:\Windows\system32> DISM /online /get-capabilities

Deployment Image Servicing and Management tool
Version: 10.0.14393.0

Image Version: 10.0.14393.0

Capability listing:

Ill Save you the hassle of all the language packs and get to the meat of it:

Capability Identity : Language.Handwriting~~~en-US~
State : Installed

Capability Identity : Language.OCR~~~en-US~
State : Installed

Capability Identity : Language.Speech~~~en-US~
State : Installed

Capability Identity : Language.TextToSpeech~~~en-US~
State : Installed

Capability Identity : Print.EnterpriseCloudPrint~~~~
State : Installed

Capability Identity : Print.MopriaCloudService~~~~
State : Installed

After working with the client, turns out if you’re using WSUS or SCCM, and do not have the feature packs enabled, it can cause the features to not be found. This blog from Stephen Wagner helps point out a work around:

Enable download of “Optional features” directly from Windows Update
  1. Open the group policy editor on your domain
    and create a new GPO scoped to the server in question, OR open secpol.msc on your server to modify the settings locally

  2. Navigate to “Computer Configuration”, “Policies”, “Administrative Templates”, and then “System”.
  3. Double click or open “Specify settings for optional component installation and component repair”
  4. Make sure “Never attempt to download payload from Windows Update” is NOT checked
  5. Make sure “Download repair content and optional features directly from Windows Update instead of Windows Server Update Services (WSUS)” IS checked.
  6. Wait for your GPO to update, or run “gpupdate /force” on the machine.

Get Exchange Install Path, Version and Role

I’ve been fighting for a while to find a GOOD script that can do everything from one machine and still work on Exchange 2010 while supporting Exchange 2013/2016. I spent the day working on this sucker so i can send it off to a client to perform an assessment without physically touching the environment and here it is. Enjoy!

Update: I’ve taken my whole script and put it out on my GitHub – check it out!

#Get Exchange Server Versions
#Be sure Powershell Remoting is enabled
#To enable on each server run winrm quickconfig
#Created by Chris Blackburn http://memphistech.net

$exchangeservers = Get-ExchangeServer

$report = @()

foreach ($srv in $exchangeservers)

$srv = Get-ExchangeServer $srv

$server = $srv.Name
if ($srv.AdminDisplayVersion -match “Version 14”) {$ver = “V14”}
if ($srv.AdminDisplayVersion -match “Version 15”) {$ver = “V15”}

Write-Host “Checking $server”

$installpath = $null

$installpath = Invoke-Command –Computername $server -ScriptBlock {$env:ExchangeInstallPath} -ErrorAction STOP
Write-Warning $_.Exception.Message
$installpath = “Unable to connect to server”

Write-host “Install Path is: ” + $installpath
$Path = $installpath + “Bin\ExSetup.exe”
$fileversion = (Get-Command $Path).FileVersionInfo
Write-Host “File Version is: ” + $FileVersion.fileversion

$serverObj = New-Object PSObject
$serverObj | Add-Member NoteProperty -Name “Server Name” -Value $server
$serverObj | Add-Member NoteProperty -Name “Install Path” -Value $installpath
$serverObj | Add-Member NoteProperty -Name “Server Role” -Value $srv.serverrole
$serverObj | Add-Member NoteProperty -Name “Server Version” -Value $fileversion.fileversion

$report += $serverObj

Clear-variable srv
Clear-variable server
Clear-variable installpath
Clear-variable ver

$report | export-csv exchangeversions.csv -notype

Quickly Change Authentication models in Azure AD / Office 365

In 2017 Microsoft has made some major improvements to their Managed authentication model to make it a viable competitor to the cumbersome Federated model. As a refresher, Federated identity requires Microsoft ADFS infrastructure deployed (along with ADConnect for AD Sync), and to make it highly available entails multiple servers deployed in multiple datacenters/Azure, global load balancing of the internet-facing URL with Azure Traffic Manager – dependencies on your private cloud to authenticate to the public cloud. Managed identity still uses ADConnect for AD Sync but the biggest drawback is that you didn’t get the “seamless” single signon (SSO) experience that ADFS provides, only “same sign on” (SSO) and needing to reenter your credentials.

Microsoft has recently added Seamless Single Signon and Pass-Thru Authentication (as an alternative to password-hash synchronization in high security environments, but out of scope for this article) to ADConnect, in efforts to further eliminate the ADFS dependencies previously mentioned, and with this I’ve been working a large number of projects in planning / executing a move away from ADFS.

What I’ve found is that it’s always been a grey area on how long this process takes, given most of the documentation calls for using the Convert-MSOLDomainToStandard cmdlet and dealing with the password conversion process. If you follow these steps there’s an easier way to do it.

Step 1 – Check Local Active Directory

The first step is ensuring that you have local AD setup and able to support Password Sync. One of the Microsoft Premier Field Engineers (PFE) wrote a great blog on this in 2016:

“First, ensure your Azure AD Connect Sync ID has “Replicate Directory Changes” and “Replicate Directory Changes All” permissions in AD (For Password Sync to function properly). If you did not set this up initially, you will have to do this prior to configuring”

This can be done thru Active Directory Users & Computers


Continue reading “Quickly Change Authentication models in Azure AD / Office 365” »

Office 365 Whitelist URLs for Firewalls & Trusted Sites

With the ever growing list of Microsoft Office 365 services comes a growing number of URLs to whitelist on web application firewalls, proxies, and IE trusted sites lists. The full list, which can be found at https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2, is quite intensive and for my own sake (and that of my clients) I’ve created the abbreviated list below to save not only the community but myself some time!


Creating an Offline install of Office 365 Pro Plus

So how do you create an offline installation of Office 365 Pro Plus for distribution on machines when you don’t want them all chewing up the internet connection at once?

First, download the Office 2016 Deployment Tool from:


(Note: you can reuse this tool to download Current branch versions each month, however Microsoft does update this to support new deployment features and resolve deployment bugs so check back often for new versions!)

Run the EXE and extract to a folder – It will only produce setup.exe

image image

Open a command prompt and browse to the extract folder, and run setup.exe /download


This will sit here for a bit while it downloads the current build to the subfolder under \Office\Data with the build number. As you can see here, the build is primarily 32-bit but provides 64-bit support as part of the installation.

In this case, this folder sits on a file share (which we’ll get to in a moment) that will serve as our “SourcePath”




The next part to performing the deployment as part of an administrative install is to create the configure XML file. You can read more about the syntax, formatting, etc at:

In an enterprise environment, it’s typical that you will have a Deferred and a Current branch (to borrow from Microsoft terminology).

The SourcePath is our Deferred that goes as the core install for all our machines, and the Updates path (towards the bottom) is another folder that we run our download process again on a monthly basis for the Current branch. Whenever a new version of the current branch is downloaded to the Updates folder, it will “update Office to the newest version. Only the files that have changed in the new version will be updated”

To perform the actual install, we need a configuration XML to use in conjunction with the setup file to perform the full Offline install. For this I like to use the online XML Configuration File editor, located at https://officedev.github.io/Office-IT-Pro-Deployment-Scripts/XmlEditor.html

<Add OfficeClientEdition=“32” Channel=“Current” SourcePath=“\\network\path”> <Product ID=“O365ProPlusRetail”>
<Language ID=“en-us”/>
<Property Name=“AUTOACTIVATE” Value=“1”/>
<Property Name=“FORCEAPPSHUTDOWN” Value=“TRUE”/>
<Property Name=“SharedComputerLicensing” Value=“0”/>
<Property Name=“PinIconsToTaskbar” Value=“TRUE”/>
<Logging Level=“Standard” Path=“c:\windows\temp”/>
<Display Level=“None” AcceptEULA=“TRUE”/>
<Updates Enabled=“TRUE” Channel=“Current” UpdatePath=“\\network\path”/> </Configuration>

From our workstation we can manually run (or use a deployment tool like SCCM to push out Office 2016 to the enterprise) using the setup.exe /configure switch.

Then before you know it, volia!





Quickly Enroll PCs with Intune

There are 2 easy ways to get the Intune client installed on your PCs:

Go to http://portal.manage.microsoft.com and log in with an account assigned an Intune license.

Click the information bar saying the device isn’t enrolled, and then click Enroll!


Then click Download software and run the Microsoft_Intune_Setup.exe


(Be sure you have local admin rights to perform the install first!)


Otherwise, if you want to provide the install more centrally, you need to log into:


From there under Admin go to Client Software Download


Click the button to download


Keep in mind this is specific to the tenant itself


As it includes the installer EXE and the certificate specific to your tenant


Now you’ll want to extract the EXE and cert to a folder (let’s say C:\temp\InstallIntune) and double-click on the EXE to start the install.

However if you’re looking to deploy Intune with a new PC image (such as part of a Windows 10 rollout) in an Enterprise environment, you’ll want to prepare setup and the enrollment process properly.

You’ll still want to extract the installer to the hard drive, but then create a setup_intune.cmd and place it under %windir%\setup\scripts. This is important because it finalizes portions of the install BEFORE any users sign on for the first time.

Here is the contents of the setup_intune.cmd:

%windir%\system32\reg.exe add HKEY_LOCAL_MACHINE\Software\Microsoft\Onlinemanagement\Deployment /v
WindowsIntuneEnrollPending /t REG_DWORD /d 1
%systemdrive%\temp\InstallIntune\Microsoft_Intune_Setup.exe /PrepareEnroll

Now once your machines start to come online and users login, their machines will enroll with Intune

Migrating Public Folders from 2010 to 2016

A little over 5 years ago I wrote a blog on how to migrate public folders from Exchange 2007 to 2010, hoping that that would be the last migration path that would be needed for the long standing public folder system. Surprise! Exchange 2013 brought along “Public Folder Mailboxes”, which brought new life into the age old structure, and killed off the dreaded replica process in lieu of DAG replication. On top of this new process has brought some new headache, as well as some old ones that have been around since Exchange 2003. We’re going to try and tackle those problems before we get down to the actual process of migration.

But let’s jump ahead before we come back and look at the age old issue of public folder migrations: mail-enabled public folders. The issue that has stemmed back to the older days of Exchange is how the Alias field allowed use of what are now seen as invalid characters. Sure the Technet article for migrating public folders gives us a script for searching for forward slashes but not invalid characters, which you may still see from environments migrated from Exchange 2003


When you mail-enable a public folder pre-Exchange 2010, it would create these as Public Folder objects in Active Directory under the Default naming context | Microsoft Exchange System Objects. As you can see on the left in the Public Folder Management Console, the mail enabled public folders, indicated by a folder with an envelope on it, correspond to the object on the left in AD.


If we open Exchange Powershell on Exchange 2010, we can find these any folders with illegal characters rather quickly:

Get-MailPublicFolder -ResultSize Unlimited | Where-Object{$_.alias -match ‘\s’}

Error: Property expression “RA (Malcolm) 2009-19” isn’t valid. Valid values are: Strings formed with characters from A to Z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more periods may be embedded in an alias, but each period should be preceded and followed by at least one of the other characters. Unicode characters from U+00A1 to U+00FF are also valid in an alias, but they will be mapped to a best-fit US-ASCII string in the e-mail address, which is generated from such an alias.

This can quickly return a LOT of errors that correspond not only to illegal characters. Some of these are completely normal and have to do with the original Offline Address Book and it’s traditional Public Folder distribution method.

image Continue reading “Migrating Public Folders from 2010 to 2016” »

Enabling Access to Security Groups in MIM for All Users

I have a customer that is looking to give normal users access to view and request access to Security groups thru MIM so I whipped this up!

Under Management Policy Rules search for Security to minimize your scope


Enable the following rules by disabling “Policy Is Disabled”

Security group management: Users can read selected attributes of group resources
Security group management: Users can add or remove any member of groups subject to owner approval



When you’re done these rules should reflect “No” in the Disabled column!!!!

Then change the Requestors on these following rules from Security Group Users to All Users and Groups

Security group management: Users can add or remove any member of groups subject to owner approval



Security group management: Users can read selected attributes of group resources



Next, under Administration go to Search Scope


Edit the following item and add the Usage keyword


Do the same thing in Administration under Navigation Bar Resource



Edit the following item and add the Usage keyword


Whenever you make UI changes, you need to perform an IISRESET on the Portal server

Now log in as your user and you should see the Security group section the same way an Administrator should see it.