Deploying an Azure AD Joined machine to existing hardware with MDT and Windows Autopilot

We’ve recently started a refresh of our staff laptops to provide a better remote working experience, as well as baselining a common standard to their configuration (Windows 10, Office 365, BitLocker etc.) At this point we were also faced with a decision on how best to deploy this:

  • domained with DirectAccess
  • domained with VPN
  • Azure AD Joined

https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-Join-on-Windows-10-devices/ba-p/244005

Given that we’re heavy users of Office 365 I decided to give Azure AD Join a try and go for a cloud-native solution, rather than extending the reach of internal services outwards. One flaw in the plan is that I’m still trying to make a case for adding InTune to our EES agreement so have had to get a bit creative in terms of deployment rather than using MDM to do the heavy lifting.

Windows Autopilot

Whilst at Future Decoded last year I attended a demo of Windows Autopilot, which sounded a very easy way to assign Windows 10 devices and get them up and running quickly.

Ref: https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/windows-10-autopilot

However looking a bit more closely it wouldn’t do here as without InTune we can’t install any additional software and on top of that the devices we’re using need upgrading to Windows 10, rather than being nice fresh kit with the latest OS already installed. That said it still has a part to play in this deployment, more on that later…

MDT time

So with that initial thought discounted we turn back to trusty MDT. Having already gained its Windows 10 deployment stripes over summer I wondered if there’s a way to make a Task Sequence that will give a similar Autopilot experience but with a bit more flexibility around apps and re-using existing kit.

A fresh Task Sequence was created to handle the usual driver packs, generic Applications and machine naming. Now time for the fun part of integrating Office 365 ProPlus and Azure AD Join!

Deploying Office 365 ProPlus

Before we get to the Azure AD Join we need to deploy some basic software to the machine such as Chrome, VLC and, of course Office Apps. Internally we use Office 2016 ProPlus but for these Azure AD Joined devices Office 365 ProPlus is a better bet in order to ensure smooth SSO from the Azure AD account.

Deployment of Office 365 ProPlus looks a lot simpler now than it was previously thanks to Microsoft creating a handy web app for generating the Configuration XML file you need for deployment.

First download the Office Deployment Tool
https://www.microsoft.com/en-us/download/details.aspx?id=49117

Then create the XML file using the Office Customization Tool, configuring your desired options
https://config.office.com/

Place all the files in a folder on your MDT server, along with a new file called install.cmd using the code from Rens Hollanders’ instructions (you don’t need to use his config.xml though as the one from the Customization Tool does the same job and is a bit more granular in terms of installation options)
http://renshollanders.nl/2015/08/office-365-updated-deployment-guide/

Finally create an MDT Application (with source files pointing to the folder above) that runs install.cmd

In your Task Sequence add this and any further Applications you wish to install in the usual place under State Restore.

If using a Volume Licensing versions of Windows I also create an Application to install the MAK product key at this point.

Preparing for Azure AD Join

Now at this point you have a pretty bog standard Task Sequence and might be wondering how we get back to the first-run wizard. The reason for this is because it’s where we get our only chance to properly join to Azure AD if we want to log into the machine using an Office 365 account, otherwise if you join later on you end up with a mix of a local account connected to Office 365, which we don’t want.

The process of getting back to that OOBE wizard is simpler than you might think and just requires one command at the end of your Task Sequence

cmd /c c:\windows\system32\sysprep\sysprep.exe /oobe /quiet /quit

This does assume a couple of things though:

  • your Deployment Share is configured with SkipDomainMembership=YES and JoinWorkgroup=WORKGROUP
    these are already set on my Deployment Share as I prefer to Join Domain manually via a TS step; that way I can control exactly when domain policies come down to the machine during deployment, or in this case not join a Domain at all
  • your FinishAction in MDT is set to SHUTDOWN
    you can either set this at Deployment Share level or override it (as I do) for a single TS by adding this step in early on…

With this configured the machine will automatically run sysprep and return to OOBE state, ready for the user (or admin) to join the machine to Azure AD via the first-run wizard.

Provisioning Packages and customisation

Now what we have so far is good, but we can go a bit further and add some InTune-esque customisation of the deployed system via the MDM method of Provisioning Packages. This will allow you to prepare an identical base set of machines that you can quickly customise by plugging a USB stick into them at the OOBE screen for any additional changes. It’s also a good insight into how the policies, or should I say CSPs (Configuration Service Providers) work.

To create a Provisioning Package you need to open the Windows ICD, which in turn is part of the ADK (don’t you just love acronyms!)
https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install

Windows Configuration Designer provisioning settings (reference)
https://docs.microsoft.com/en-us/windows/configuration/wcd/wcd

I initially started with this side of things via the Set up School PCs app but ended up opening up the package it built manually to take a look exactly what it did. Not all the settings were required so I decided to build a new one from scratch. Again it gives a good idea what’s going on “under the hood” though 🙂

Ref: https://docs.microsoft.com/en-us/education/windows/use-set-up-school-pcs-app

Applying the package file from a USB when OOBE appears works fine but I couldn’t resist the automated approach outlined in the post below to do it via MDT. If you’re using one of the latest builds of Windows 10 note the comment at the bottom that you don’t appear to need to sign the packages for 1803 onwards.

Ref: http://chrisreinking.com/apply-a-provisioning-package-with-mdt/

However I found that in MDT running the AddProvisioningPackage Powershell command with a UNC path didn’t work, giving me “path not supported errors”.

There’s not much documentation online about using this particular cmdlet (most people seem to be using DISM instead) but I found that if you map a drive letter to the Application path it works fine. My code for this is below (also includes the nifty transcript logging wrapper from deploymentresearch.com so you get full visibility of the process in your MDT Logs folder)

# Determine where to do the logging 
# https://deploymentresearch.com/Research/Post/318/Using-PowerShell-scripts-with-MDT-2013

$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment 
$logPath = $tsenv.Value("LogPath") 
$logFile = "$logPath\$($myInvocation.MyCommand).log"
$DeployRoot = $tsenv.Value("DeployRoot")

# Start the logging 
Start-Transcript $logFile
Write-Output "Logging to $logFile"

net use P: "$DeployRoot\Applications\Provisioning Package - Your Name"

Write-Output "Adding TrustedProvisioners Registry Key"
Start-Process -filepath "C:\windows\regedit.exe" -argumentlist "/s P:\TrustedProvisioners.reg"

Write-Output "Adding Provisioning Package from folder: $DeployRoot\Applications\Provisioning Package - Your Name mapped to P:"
Add-ProvisioningPackage -Path "P:\Provisioning Package - Your Name.ppkg" -ForceInstall

# Stop logging
Stop-Transcript

Note: you need to copy the entire contents of the folder where the signed exported Provisioning Package is created for the silent install to work correctly. Thanks to Dhanraj B for pointing this out in the Technet forums otherwise I may well have given up on it…

https://social.technet.microsoft.com/Forums/en-US/a01ad169-7aaa-42be-937a-e82169f88d4f/provisioning-and-code-signing?forum=win10itprosetup

If you followed the Chris Reinking instructions to the letter you should see a successful import in your logs, which looks something like this…

IsInstalled : False
PackageID : d69c654b-3546-4b77-abcd-93f09285c123
PackageName : Provisioning Package - Your Name
PackagePath : P:\Provisioning Package - Your Name.ppkg
Description :
Rank : 1
Altitude : 5001
Version : 1.17
OwnerType : ITAdmin
Notes :
LastInstallTime : 22/11/2018 15:51:52
Result : 0__Personalization_DeployDesktopImage.provxml
Category:Content
LastResult:Success
Message:Provisioning succeeded
NumberOfFailures:0 (0x0)

1__Personalization_DeployLockScreenImage.provxml
Category:Content
LastResult:Success
Message:Provisioning succeeded
NumberOfFailures:0 (0x0)

2__Personalization_DesktopImageUrl.provxml
Category:UxLockdown
LastResult:Success
Message:Provisioning succeeded
NumberOfFailures:0 (0x0)

3__Personalization_LockScreenImageUrl.provxml
Category:UxLockdown
LastResult:Success
Message:Provisioning succeeded
NumberOfFailures:0 (0x0)

Start Menu layout

One part of ICD that I found didn’t seem to work at all was Start Menu layout deployment. In Active Directory land it’s a simple GPO but despite following the MS documentation to the letter it never applied despite the Provisioning Package working otherwise.

Instead of using the ICD method I took an easy way out and created another Application in MDT, which copies the desired LayoutModification.xml to the Default User AppData folder:

cscript.exe CopyFiles.vbs C:\Users\Default\AppData\Local\Microsoft\Windows\Shell

Get CopyFiles.vbs from here https://mdtguy.wordpress.com/2014/07/30/how-to-copy-folders-in-mdt-like-a-boss-the-easy-way/

The final piece of the puzzle – automatic Azure AD Join

At this point we’re very close to having a hands-off deployment but we need a method to join the machine to Azure AD itself. Of course you can do this manually if you wish; the machine at this point can be handed to a user to complete the OOBE wizard and they’ll be able to log in with their Office 365 credentials.

Be mindful that the user who performs the Azure AD Join becomes local admin on that device. If you don’t want this you’ll need to use the method below to get a bit more control.

Initially I thought the Azure AD Join would be simple as there’s an option sitting right there in the ICD wizard
https://docs.microsoft.com/en-us/intune/windows-bulk-enroll

However the URL gives away what seems to be the crux of the issue in that you need an InTune license to get the Bulk Token 😦 When I try it fails miserably with the error “Bulk token retrieval failed”

Again documentation on this isn’t exactly forthcoming but there’s one particular Technet post by a Microsoft staffer that suggests it is limited by licensing.

“By the way, the error message “Bulk token retrieval failed” might be caused if there are no more licenses available for Azure AD Premium and Microsoft Intune”

Interestingly the Set up School PCs app is able to join to Azure AD in bulk, which suggests Microsoft can enable this functionality to non-InTune users when they feel like it but seemingly not for ICD use.

Windows Autopilot returns

Remember I said I’d return to Autopilot… well, “later” in the post has now arrived and it’s time to make use of it.
https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/windows-autopilot

Without InTune we can still configure Autopilot using the Microsoft Store for Business (or Microsoft Store for Education if you’re an edu user). You’ll need to set it up if you haven’t already…
https://docs.microsoft.com/en-gb/microsoft-store/windows-store-for-business-overview

and then access it via one of the links below

https://businessstore.microsoft.com/en-gb/store
https://educationstore.microsoft.com/en-gb/store

Now follow the steps below:

At this point once your freshly imaged device hits the OOBE screen it’ll connect to Autopilot, apply the profile settings and skip all screens apart from bare minimum input required from the user for keyboard layout and login info. Once they log in Office 365 will already be installed, along with any other apps you provisioned via the Task Sequence and the device will be branded up as per your organisation’s design (provided you’ve configured this in the Azure Portal)

Note: during my testing Autopilot didn’t seem to work so well with a Hyper-V VM. The gather script managed to obtain 3 different sets of hardware hashes for the same VM on 3 separate image attempts, whereas on physical laptops the data was gathered consistently. One to keep an eye on but it was a case of third time lucky in this case, which allowed for some nice screenshots of the end product…

Multiple user access

An interesting observation during this process was the mysterious appearance of the “Other user” button, which I’d been chasing on Azure AD Joined machines for a while before this but without much joy. As you can imagine I was quite pleased when it popped up after running the first couple of test Task Sequences.

I’m not sure if it’s a recent Windows Update, enabling some of the “Shared PC” settings in ICD or (more likely) the additional of Azure AD Premium P1 licenses on our Office 365 tenant but it makes an Azure AD Joined machine much more usable for our use case, where machines need to be loaned out to multiple members of staff.

If anyone can clear up this quandary it’d be great to hear from you!


Note the use of the branded login screen to add some additional instructions for the user to help them log in for the first time 🙂

At this point once your freshly imaged device hits the OOBE screen it’ll connect to Autopilot, apply the profile settings and skip all screens apart from bare minimum input required from the user for keyboard layout and login info.

Once they log in Office 365 will already be installed and visible on the (customised) Start Menu, along with any other apps you provisioned via the Task Sequence and the device will be branded up as per your organisation’s design (provided you’ve configured this in the Azure Portal)

And here’s one we made earlier…

Not bad eh 😉

Troubleshooting

If Autopilot doesn’t work check network connectivity first, particularly if using a proxy server internally

https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/windows-autopilot-requirements-network
https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/troubleshooting

 

image credit: blickpixel – https://pixabay.com/en/gift-made-surprise-loop-christmas-548290/

Advertisements

OneDrive Files on Demand – update!

OneDrive logo

After our initial post getting the new Windows 10 1709 OneDrive client up and running with Files on Demand we had one or two little snags left to fix. Both of which are now resolved so thought I’d make a quick ICYMI post to cover the final pieces of the puzzle to getting everything up and running perfectly 🙂

Outdated client on the image

In true MS fashion the 1709 ISO ships with the old OneDrive client (epic fail) which means users have an annoying wait while it updates. There’s also the possibility to start off with the wrong client and therefore syncing files down by mistake.

I was trying out an updater script that would copy over the new client but didn’t have much success in MDT. After looking more closely at the logs with CMTrace I could see it failing on the copy operation so I added a Suspend action and tried each step manually. That flagged up an access denied error.

I then realised that MDT runs its scripts as the local Administrator user rather than SYSTEM as SCCM would, therefore the script’s permissions need tweaking for MDT use:

%SYSTEMROOT%\system32\takeown /f %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log
%SYSTEMROOT%\system32\icacls %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe /Grant Administrator:(F) >> %SYSTEMROOT%\logs\Onedrive.log
Copy OneDriveSetup.exe %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log /Y
%SYSTEMROOT%\system32\icacls %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe /Remove Administrator:(F) >> %SYSTEMROOT%\logs\Onedrive.log

This works like a charm! The updated client is installed during the Task Sequence and the first run as a user now begins with the 2017 client.

I’m also thinking of setting up a scheduled task on the MDT server to pull down the latest OneDrive client at regular intervals so the Task Sequence always deploys the latest version. That should do the trick until Microsoft see sense and push it out properly via WSUS.

Silently configure OneDrive using the primary Windows account

The final piece of the puzzle is to make the client log in via SSO so users have a fully configured OneDrive without any additional login prompts. I was puzzled by this not working initially as the GPO looks straightforward but it didn’t seem to do anything.

I’d read that the SSO relies on ADAL (aka modern authentication) so I initially wondered if our SSO provider hadn’t implemented that yet. That didn’t seem to make much sense as ADAL has been out for a while now so I hit Google a bit more deeply to try and find some further detail.

Soon came to this page, which I’m sure I’ve seen before:

Ref: https://support.office.com/en-gb/article/Use-Group-Policy-to-control-OneDrive-sync-client-settings-0ecb2cf5-8882-42b3-a6e9-be6bda30899c#silentconfig

The key (pun not intended, honest!) is the EnableADAL.reg file that’s squirrelled away at the bottom of the page. Deploy that via GPP et voila, one perfect blue OneDrive icon without any user interaction 🙂

What next?

Having got Files on Demand working how we want with minimal cache, SSO and the latest client we can now move onto piloting it with our users. I’ve been tweaking Windows 10 GPOs today for some of the newer features such as Windows Defender Security Center, Exploit Protection etc. so the configuration is looking good enough for some early adoption!

OneDrive Files on Demand – first steps

OneDrive logo

After much anticipation and playing with Windows Insider previews OneDrive Files on Demand finally hit general release alongside Windows 10 1709 (Fall Creators Update) the other week. I’ve been giving it a test drive over the past week or two along with fellow Network tech Matt Stevens – here’s a few of our observations so far along with workarounds for a couple of teething issues.

Windows 10 build

There is one pretty important requirement to bear in mind with the new Files on Demand feature; it’s only available in build 1709 and above. That means you need to be on the semi-annual (aka CB) branch rather than the LTSB route that some people have taken.

Ref: https://blog.juriba.com/windows-10-branching-timeline

It’s new features like Files on Demand that make the additional work of staying up-to-date worthwhile; so far we have a couple of hundred laptops running 1703 without too much fuss so 1709 should slot in fairly smoothly as we build our images layer-by-layer now using only the pure Microsoft WIM as a starting point.

We tamed (nuked) the built-in apps via a very handy Powershell script we found online (also see alternative version here) that runs during MDT deployment and the Start Menu default tiles are cleaned up via a GPO layout file. Configure your Windows Store for Business (or Education as case would have it), tweak a few more policies for Cortana, Telemetry etc. and Windows 10 becomes much more manageable even on the latest build.

Why Files on Demand?

If you don’t know what all the fuss is about check out the initial Insider announcement:

Ref: https://blogs.windows.com/windowsexperience/2017/06/13/onedrive-files-demand-now-available-windows-insiders/#kwLbqguOTefId6pv.97

Ref: https://blogs.office.com/en-us/2017/05/11/introducing-onedrive-files-on-demand-and-additional-features-making-it-easier-to-access-and-share-files/?eu=true

What it basically means is that we can finally integrate (huge amounts of) cloud storage with our on-premise desktops in a much tighter fashion and dispense with (unsupported) scripts or (expensive) third party tools to access OneDrive on a Windows desktop using File Explorer. It also means not having to deal with WebDAV, which always felt a horribly dated and clunky protocol to use for accessing cloud storage.

As soon as the 1709 ISO hit VLSC I grabbed it from Microsoft, slotted the new WIM into one of my MDT Task Sequences and deployed a VM to give the production version a try. It shows much promise but as always there’s some gotchas that mean nothing is ever quite straightforward.

Client version

Microsoft being Microsoft always have one shoot-self-in-foot moment whenever a new product comes out and this release was no exception. Despite having the freshly downloaded 1709 ISO I noticed that on first launch the client was showing up as 2016 and not the latest 2017 (17.3.7076.1026) that brings in Files on Demand

https://support.office.com/en-gb/article/New-OneDrive-sync-client-release-notes-845dcf18-f921-435e-bf28-4e24b95e5fc0


that’s the one that you want…

There’s a useful summary of the client install \ update process below. It does strike me as odd that the client self-updates and installs from appdata rather than being managed by WSUS.

Ref: http://deploynovellas.com/2016/05/25/install-onedrive-ngsc-update-windows-10-osd

Similarly it also takes a while to update when deployed on a clean 1709 build due to the initial client being out-of-date. This also means if a user is a bit too quick off the mark they can end up with an old-school full sync rather than Files on Demand.

I’ve been trying to replace the client during the deployment Task Sequence but more testing is required as my initial attempt failed with “Application Microsoft OneDrive 17.3.7073.1013 returned an unexpected return code: 1”.

Ref: http://model-technology.com/next-gen-onedrive-deployment-during-sccm-osd

I’ve added a Suspend action to the Task Sequence and will examine the logs to see what’s going on as the script tries to run…

Group Policy

To get more control over how the client is used grab the updated Group Policy templates from the local installation folder %localappdata%\Microsoft\OneDrive\BuildNumber\adm\

Ref: https://support.office.com/en-gb/article/Use-Group-Policy-to-control-OneDrive-sync-client-settings-0ecb2cf5-8882-42b3-a6e9-be6bda30899c

We force Files on Demand to be enabled as we don’t want sync cache eating up drive space on machines. We also configure our tenant ID (found via the Azure AD portal) so only Office 365 accounts can be used.

Configure these under Computer Settings > Administrative Templates > OneDrive

  • Allow syncing OneDrive accounts for only specific organizations > Enabled (using Tenant ID)
  • Enable OneDrive Files On-Demand > Enabled
  • Silently configure OneDrive using the primary Windows account > Enabled

I need to check if our third-party identity provider supports ADAL to make sure that last GPO setting works correctly. In the future we may well move to Azure AD Connect Passthrough authentication instead.

Clearing local cache (Free up space)

One important thing to remember about using Files on Demand is that when a file is either downloaded from the cloud, or freshly uploaded to it a cached copy will be kept on the local machine.

Over time (or with a large upload) this cache could grow and cause similar issues to what we were trying to avoid, especially with a shared machine and large volumes of users (pretty much the case for all our classroom machines)

At present it seems that no policies exist to force the “Free up space” option that removes the cached copies of files. However the article below suggests that using the new file attributes that have been brought in with 1709 can automate the process.

“Attrib.exe enables 2 core scenarios.  “attrib -U +P /s”, makes a set of files or folders always available and “attrib +U -P /s”, makes a set of files or folders online only.”

https://techcommunity.microsoft.com/t5/OneDrive-Blog/OneDrive-Files-On-Demand-For-The-Enterprise/ba-p/117234

We tried a script that runs on the root OneDrive folder and sure enough it resets all files back to Online only and reduces the space used down to a megabyte or so 🙂

cd "%userprofile%\Onedrive - Name of your Organisation"
attrib +U -P /s

Running this script on Logoff should in theory keep the cache files down to the bare minimum.

Disclaimer: we only just figured this one out today so again caveat emptor if you go and run this in production without testing it first!!!

Server 2016 RDS via Azure AD Application Proxy end-to-end guide

remote_desktop_blueOne of our priorities for this year was to improve our remote access offering to staff to enable more flexible working whilst outside of college. Office 365 helps greatly and has already improved functionality in many ways but there’s still some legacy applications and classic file shares that need to be provided remotely too. If at all possible we prefer the files not to leave the network so some form of virtual desktop looked the way to go.

After discounting VMware and Citrix offerings on cost grounds the improvements to Microsoft’s RDS offering in Server 2016 seemed to come at a perfect time.

Even more so now we’ve implemented Azure AD Application Proxy (more on that shortly!) We’ve also recently decommissioned some services that freed up a bit of physical hardware resource to “play” with so away we went!

Server installation

The physical hardware for now is running on some reclaimed Dell PowerEdge R610 servers; 64GB RAM, dual CPU and 6 x 15k disks in RAID10. Should be plenty to get us up and running with the RDS roles eventually split across two hosts. For now we’re running on just the one but even that’s plenty to get up and running with.

We installed Server 2016 Core running the Hyper-V role, which was simple enough. The Core role looks to be a tad more polished in Server 2016, although not new the sconfig tool got the main settings entered with fairly minimal fuss.

r610
yes it will go back in the rack once we’re done with it!

Getting the OS to update correctly wasn’t so simple due to Microsoft doing something silly to the update mechanism in the initial release of Windows 10 1607 and its equivalent Server 2016 release. Update status was stuck on “Downloading” showing no signs of progressing. In the end manually installing the latest Cumulative update release from the Microsoft Update Catalog did the trick e.g.

wusa.exe windows10.0-kb3213986-x64_a1f5adacc28b56d7728c92e318d6596d9072aec4.msu /quiet /norestart

Server roles

With Hyper-V up and running the next stage was to install our guests. We went with 3 VMs set up as follows:

  • Connection Broker \ RD Licensing
  • RD Web Access \ RD Gateway
  • RD Session Host

The original plan was to try and embrace the Server Core concept and only install the GUI where absolutely necessary. With that in mind we made the first two servers with Core and only the Session Host with a GUI. More on that soon… (!)

add-roles-wizard
RDS deployment wizard Role Services

Running the deployment through Server Manager on my desktop was easy going, Microsoft have done good work with this and the deployment doesn’t seem too far removed from the 2012 R2 guides I’ve been looking at online. We added each server to the roles as per above, got to the final screen and hit the magic Deploy button then…

"Unable to install RD Web Access role service on server"

Role service... Failed
Deployment... Cancelled

Well that didn’t go to plan! We had a look online, trying to find reasons for the failures and went through some initial troubleshooting to make sure all recent updates were installed and each server’s patches matched exactly, also enabled Powershell remoting…

Enable-PSRemoting -force

…still no joy until we found this little nugget of information…

Ref: https://social.technet.microsoft.com/Forums/Sharepoint/en-US/b5c2bae3-0e3b-4d22-b64d-a51d27f0b0e4/deploying-rds-2012-r2-unable-to-install-rd-web-access-role-service-on-server?forum=winserverTS

So it appears the RD Gateway \ RD Web Access role isn’t supported on Server Core. Of course we wouldn’t want the web-facing part of the deployment running on a server with reduced attack surface would we Microsoft… not impressed!

Ref: https://technet.microsoft.com/en-us/library/jj574158(v=ws.11).aspx

To confirm the hypothesis running Get-WindowsFeature on Server 2016 Core gives this…

server-core-available-rds-roles
Server Core

and on Server 2016 with GUI gives this…

server-gui-available-rds-roles
Server with GUI

Published names & certificate fun and games

After begrudgingly re-installing one of the VMs with a GUI (seemed quicker than trying to convert the Core install) we managed to get past the final Deploy page with 3 success bars 🙂

The first key setting we were asked for was the external FQDN for the RD Gateway, which was added to our ISP-hosted DNS records. We use a wildcard certificate to cover our external facing SSL needs, nothing out the ordinary there and went on to apply it to each of the four roles specified by the RDS Deployment wizard. A Session Collection was created for a test group and pointed at the new Session Host. All looking promising.

The RD Gateway FQDN naming in itself wasn’t a problem but led us to an interesting part of the setup relating to SSL certificates and domains. Once we had the RDS services accessible from outside the network (see below) I fired up my 4G tethering to give it a test.

The connection worked but threw up a certificate warning and it was obvious to see why. Our wildcard certificate is for *.domain.ac.uk but the Connection Broker’s published FQDN is servername.subdomain.domain.ac.uk and therefore isn’t covered.

Fortunately a Powershell script called Set-RDPublishedName exists to change this published name and works a treat! Grab it from https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80

You’ll also need to ensure that you can access the new published name internally, depending on what form your internal domain is vs. your external you may need to do a bit of DNS trickery with zones to get the records you need. More on that can be found at:

Ref: https://msfreaks.wordpress.com/2013/12/09/windows-2012-r2-remote-desktop-services-part-1
Ref: https://msfreaks.wordpress.com/2013/12/23/windows-2012-r2-remote-desktop-services-part-2

set-rdpublishedname
Set-RDPublishedName script in action

External access via Azure AD Application Proxy

We published the RD Gateway and RD Web Access via our new shiny Azure AD Application Proxy for a few reasons…

  • simplicity, no firewall rules or DMZ required
  • security, leverages Azure to provide the secure tunnel
  • SSO, use Kerberos Delegation to sign into RD Web Access as part of the user’s Office 365 login

I followed the excellent guides from Arjan Vroege’s blog for this, in particular the section regarding how to edit the RD Web Access webpage files… nice work Arjan!

Publish your RDS Environment with Azure and AD Proxy – Part 1 – http://www.vroege.biz/?p=2462
Publish your RDS Environment with Azure and AD Proxy – Part 2 – http://www.vroege.biz/?p=2563
Publish your RDS Environment with Azure and AD Proxy – Part 3 – http://www.vroege.biz/?p=2647

As per my previous post on Azure AD Application Proxy & Kerberos delegation use the command below to add the SPN record (replace the FQDN and server name as appropriate)

setspn -s HTTP/servername.subdomain.domain.ac.uk servername

When done the end result is a seamless login to RD Web Access via the Azure AD login page. In our case the link will eventually end up as a button on our Office 365-based Staff Intranet, therefore not requiring any further logins to get to the RDWeb app selection screen.

I particularly wanted to avoid the RDWeb login screen, which I’m amazed in 2017 still requires DIY hacks to avoid the requirement to login with the DOMAIN\username format. Thought Microsoft would’ve improved that in the Server 2016 release but evidently not.

One more gotcha

So having done all the hard work above preparing the login all that was left was to click the Remote Desktop icon and enjoy, right? Wrong.

After running the Set-RDPublishedName script the certificate warning went away and I could see the change to the new wildcard-friendly name, however the connection attempt now failed with the error “Remote Desktop can’t connect to the remote computer *connectionbrokername* for one of these reasons”

remote-desktop-cant-connect
connection failure after changing Published Name

Neither explanation made any sense as the connection was working perfectly fine until changing the Published Name. Indeed changing it back to the original FQDN of the Connection Broker restored service so it had to be something to do with that. After being stumped initially I came back after food (always helps!) then after a bit more research found this very helpful post:

Ref: https://social.technet.microsoft.com/Forums/windowsserver/en-US/4fa952bc-6842-437f-8394-281823b0e7ad/change-published-fqdn-for-2012-r2-rds?forum=winserverTS

It turns out the new FQDN we added when changing the Published Name needs to be added to RDG_RDAllConnectionBrokers Local Computer Group.

This group is used to approve connections in the Resource Authorization Policies (RD-RAP) section of RD Gateway Manager. By default only the server’s domain FQDN is present in the list (as you’d expect) so it appears unless you add the new Published Name in there the connection attempt gets denied.

To add your external published name follow these steps:

  • Server Manager > Tools > Remote Desktop Services > Remote Desktop Gateway Manager
  • expand your RD Gateway server > Policies > Resource Authorization Policies
  • Click Manage Local Computer Groups on the right hand pane
  • Select RDG_RDConnectionBrokers > Properties
  • Click the Network Resources tab
  • type the FQDN of the Published Name you supplied to the Powershell script earlier then click Add
  • OK all the way out then try your connection again

manage-locally-stored-computer-groups
RD Gateway Manager

The example below replaces the real server names with dummy entries but should illustrate the concept. The same scenario applies if your servers exist in a .local Active Directory domain (which will be the top entry) and your external domain is something different (again remember to sort out internal DNS zone entries to suit)

add-external-name-to-rdcbcomputers-group
Manage RDG_RDCBComputers group

Finishing touches

Once all the above is done you should then get a connection, there is one seemingly unavoidable credential prompt due to Microsoft persisting with using an ActiveX control to start the RDP session but perhaps one day they’ll update it (we live in hope). It seems you can use the UPN style format here which is handy as it keeps things consistent. In a way it’s a bit of a security measure so not the end of the world.

Now the connection itself is sorted out all that’s left is to tweak the Session Host to our requirements. This guide gives some nice pointers on locking down the server via GPO:

Ref: http://www.it.ltsoy.com/windows/lock-down-remote-desktop-services-server-2012

We also push out a custom Start Menu using the newer Windows 10 1607 GPO settings along with the Export-StartLayout command. Finally install any programs required, remember to change the mode of the server first:

Ref: https://technet.microsoft.com/en-us/library/ff432698.aspx

change user /install

Then once done

change user /execute

Now enjoy 🙂

rds-screenshot
Connection to Server 2016 RDS Session Based desktop via RD Web Access \ RD Gateway

Azure Active Directory Application Proxy installation and troubleshooting

11225654646_7fc9621cc9_bRecently we decided to migrate away from our legacy reverse-proxy product to something that would integrate better with our AD \ Office 365 systems. I’ve wanted to try out Azure AD Application Proxy for a while since seeing it in beta last year so this seemed a good time to get to grips with it. This post outlines a few gotchas to watch out for and some useful background reading.

Let’s start off with the initial Microsoft documentation available here

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-get-started

Education freebies

Although Microsoft’s recent price hikes haven’t come at a good time for us in education we do get a lot of extras thrown into our Microsoft licensing agreement. One of the lesser-known ones is Azure AD Basic, which is the minimum requirement to use Azure AD Application Proxy – see comparison chart at https://www.microsoft.com/en-cy/cloud-platform/azure-active-directory-features for more info

To get your free licenses you’ll need to get in contact with your EES reseller and they’ll get them added to your tenant in a similar way to Office 365.

Applying the Azure AD Basic license is nice and simple, go to your Azure Management portal at https://manage.windowsazure.com, select your Azure AD directory then assign suitable groups to the license. What’s handy is that if you’re using Azure AD Connect to sync from your on-prem directory any new users will get automatically licensed as they come on board.

Installation

Next step in the documentation list is here:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-enable

I used two dedicated Server 2012 R2 VMs for our install, the connector will be installed on each so we have failover should it be required at some point. Enabling the Application Proxy in Azure is nothing more than one click in the portal

Now in theory the installation should be straightforward, nothing more than downloading the installer from the link, sign in with admin credentials and job done. However if everything went that smoothly this blog wouldn’t exist (!)

Troubleshooting 403 Forbidden errors

At the end of the installation the wizard helpfully offers to run a troubleshooter to check all is well but in fact all was far from well…

Checking Event Viewer threw up the following errors:

  • Event ID 32012
    The Connector update using the update service failed: ‘The remote server returned an error: (403) Forbidden.’. Check your firewall settings.
  • Event ID 12020
    The Connector was unable to connect to the service due to networking issues. The Connector tried to access the following URL: ‘https://***GUID***.bootstrap.msappproxy.net:8080/’

Outbound firewall settings were already configured to allow all the ports that were asked for in the documentation, proxy was disabled in Connection Settings and the firewall didn’t register any outbound traffic being blocked so what’s going on here? The mystery deepens…

Although the wizard only offers to run the troubleshooter once you can run it again manually by launching it from:

C:\Program Files\Microsoft AAD App Proxy Connector\ConnectorTroubleshooterLauncher.exe

Troubleshooting the troubleshooter

Although there’s a fair bit of documentation in the troubleshooting section on Microsoft’s pages none of it referred to this particular error. Google didn’t have much to go on either but did throw up some useful and detailed slides from the Ignite conference that are well worth a read:

Ref: https://channel9.msdn.com/Events/Ignite/2015/BRK3864
Ref: https://techcommunity.microsoft.com/t5/Microsoft-Ignite-Content/BRK3139-Throw-away-your-DMZ-Azure-Active-Directory-Application/td-p/10675

The second link references another useful document aimed purely at troubleshooting:

Ref: http://aka.ms/proxytshootpaper

Whilst searching I stumbled across an email contact for the Microsoft Azure AD Application Proxy team

aadapfeedback@microsoft.com 

so I dropped them a message with the errors I was encountering. The team replied almost instantly and initially suggested ensuring that the following updates were applied on the server:

https://support.microsoft.com/en-us/kb/2973337
https://support.microsoft.com/en-us/kb/2975719

Proxy proxy proxy!

However still no joy even with everything present as it should be. The next recommendation was to check if I was using a proxy server for outbound connections. We do have one but it’s not used for server VLANs and is the first thing I disable on a new VM build.

However I did get intrigued to check the traffic going out via TCPView… lo and behold there was the proxy server trying to take the outbound connections and failing miserably. It seems that despite everything in the operating system suggesting traffic should be going out directly the Connector was still trying to use the proxy route instead.

Ref: https://blogs.technet.microsoft.com/applicationproxyblog/2016/03/07/working-with-existing-on-prem-proxy-servers-configuration-considerations-for-your-connectors/

The solution is in this document under the section “Bypassing outbound proxies”, which basically involves adding these lines to the .config files for both Connector and Updater services

<system.net>

<defaultProxy enabled="false"></defaultProxy>

</system.net>

Checking Event Viewer and the Azure Portal afterwards showed success, my Connectors were now up and running with nice green icons, much better 🙂

Note: even though this fix resolves the issue the current version of the Troubleshooter doesn’t seem to follow the settings in the .config files and will still report connection failures. The Azure AD Application Proxy team are aware of this and are aiming to have a new version out soon.

Additional considerations

There’s a few other points to bear in mind when you’re completing the configuration of the application proxy. None of them are major issues but good to have everything ready before you start…

Certificates

Once the Connectors are up and running the rest of the process went smoothly, although note you will need a wildcard certificate if you want to publish your applications via a “vanity” URL i.e. your own domain rather than “msappproxy.net”

Using the vanity domain and some DNS CNAME records means that if you use Office 365 SharePoint for your Intranet your internal applications can work from the same URL both inside and outside.

Setting SPNs for Kerberos SSO

Even better, those internal apps can SSO based on the Office 365 initial sign-on for a suitably slick user experience! This does require a bit more configuration with Kerberos delegation but it’s not too bad.

When setting the SPN records I remembered the gotcha from when I worked on Dynamics CRM to type the command in manually… bizarre as it is the same still applies!

Using the -S switch worked well for me:

setspn -s HTTP/yourserver yourserver

Ref: https://blogs.msdn.microsoft.com/saurabh_singh/2009/01/08/new-features-in-setspn-exe-on-windows-server-2008/

Nested groups

Finally, bear in mind if you’re using groups created natively in Azure AD you can’t nest memberships when creating application assignments, which is a shame. As a workaround create any nested ones in your local AD instead and sync them up via Azure AD Connect or just create flat groups in Azure AD if you prefer to work solely up there.

Ref: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-manage-groups

Application links

You can either publish your application links via your Intranet or users can browse them via the portal (I’ve linked to the new makeover version as it looks much better than the previous one in my opinion)

https://account.activedirectory.windowsazure.com/r#/applications

image credit Rainer Stropek 

Activate Office 365 Education email encryption using your free Azure RMS licenses

ome-iconIn order to meet Data Protection requirements for sending data to external recipients we needed to find a method of providing encrypted email functionality for our users. In Office 365 this is provided as a native feature via Azure Rights Management Services.

I vaguely remembered seeing something a while back about these licenses being available at zero cost and sure enough soon found a link confirming this as part of the plan changes that also brought us eDiscovery features.

Ordering licenses

In a similar vein to how the Student Advantage licenses were made available you’ll need to ask your EES reseller to get them activated against your O365 tenancy. For reference here’s the names and part numbers of the licenses you’ll need:

azure-rms-order

Assigning licenses

Once the order has been assigned you’ll need to add the license to any user you want to be able to use the RMS features i.e. in our case anyone who needs to send an encrypted message. If you’re using the GUI look for this:

azure-rms-o365-license

Given the number of users to assign licenses to the quickest way was via PowerShell, using a variation on the script that originally assigned our student licenses.

Tip: I initially scared the living daylights out of myself when checking which licenses were assigned after I’d ran the update script as it appeared users no longer had their Office 365 licenses.
The script (below) uses column position [0] to search the field AccountSkuID, which is all well and good until your users have multiple licenses assigned and for whatever reason they aren’t all listed in the same order (!)

I ended up having to run this code twice, once with Licenses[0] and again with Licenses[1] to pick up all the staff accounts, then checked a few random samples in the GUI for good measure:

Get-MsolUser -All | select UserPrincipalName,Licenses | Where-Object {$_.Licenses[0].AccountSkuID -eq "YOURORG:STANDARDWOFFPACK_FACULTY"} | Set-MsolUserLicense -AddLicenses "YOURORG:RIGHTSMANAGEMENT_STANDARD_FACULTY"

Once done I then ran GetMsolAccountSku and confirmed the numbers match up.
The number of office 365 licenses assigned to each staff user is now 3:

  • Office 365 Education
  • Office 365 ProPlus
  • Azure RMS

I’ve since found this very handy looking GUI license assignment tool via the Office 365 Yammer group which may make any further bulk maintenance tasks a bit less scary 🙂

https://gallery.technet.microsoft.com/office/Office365-License-cfd9489c

Usual disclaimer applies, be very careful running license update scripts, especially in bulk!

Configuring Azure RMS and Office 365 Message Encryption (OME)

Now your users are licensed jump into the Admin Portal > Service Settings > Rights Management then follow this excellent guide to switch on Azure RMS, then configure Office 365 Message Encryption.

http://office365support.ca/setup-and-enable-office-365-message-encryption/

There’s not much else to say for this step as the guide is spot on 🙂

Once you’ve set up a Transport Rule in Exchange settings sending yourself a test email with the keyword(s) you specify will generate this at the recipient’s end (sample screenshot of the message arriving in a GMail inbox).

ome-email

Office 365 service outage

7612.Office-365-logo_thumb_58DAF1E4

As many of you are experiencing right now Microsoft have had a major issue in Azure AD that has affected the Office 365 platform.

We can’t get to the Service Status page as it’s stuck behind the login page (!) but the Azure status seems to be best source of information at present:

Ref: https://azure.microsoft.com/en-us/status/#current

azure status

The outage seems to have some relation to the random issues we were seeing on DirSync in the last day or so, receiving messages stating “The following errors occurred during synchronization:” but with an empty Error Description field.

Ref: https://social.msdn.microsoft.com/Forums/en-US/2050fdd2-2392-4a93-aeb2-ac0c1120d314/aadconnect-identity-synchronization-error-report?forum=windowsazuremanagement

More to follow…