DHCP Registration of DNS Entries to an Alternate DNS Server

We are in the midst of a BYOD rollout, and one of the challenges we’ve faced is how to best provide DHCP services and DNS resolution to BYOD clients. On the surface these are not difficult items, but with BYOD you are inherently dealing with a variety of devices that are outside of your control, plus you obviously want them isolated from your production (secure) network. This implies a few things:

• If you want BYOD devices registered in DNS, your DHCP server(s) will need to handle the registration and maintenance of DNS records.
• A BYOD device that is behind your firewall yet physically isolated from production resources may need different DNS resolution than a domain-joined device. An example of this is a federation (ADFS) server; domain-joined devices connect to an “internal” ADFS server that does SSO, while non-domain devices need to connect to an ADFS proxy that accepts a manual login.

There are many posts about DHCP and/or DNS configuration, including how to handle DHCP registering DNS records. Rather than repeat anything, I’ll link to a few that I found helpful:

TechNet: Windows Server: Integration between DNS and DHCP

Ace Fekay: Dynamic DNS Updates…

Where things get a bit trickier (or perhaps less obvious) is when you want DHCP to register a client on a DNS server that is different from the DNS server assigned to that client. In our case, we want our BYOD devices registered on our Windows DNS servers, but the BYOD devices themselves need to query a DNS proxy rather than our Windows DNS servers.

We already had DHCP configured to register clients in DNS, but which DNS server? I could not find any reference for this, but based on packet captures and empirical evidence, this is what happens:

1. DHCP queries the DNS server that is being assigned to the client for the address(es) associated with the DNS domain name in DHCP option 015
2. DHCP then attempts to register the client on the address(es) returned by the prior query

Put another way…when DHCP offers a DNS server to a client via option 006, DHCP will query that same option 006 DNS server for the DNS Domain Name in option 015, in order to determine what DNS server the client should be registered on.

Long story short: the option 006 DNS server must have an entry that matches the option 015 DNS Domain Name, and resolves to the IP address of the DNS server where you actually want the clients registered.

Making Sense of Office 365 Pro Plus and Office 2019

Office 2019 recently released and accordingly, you may be looking into the upgrade process and any challenges it may bring. We recently found ourselves in this situation and the upgrade is, unfortunately, anything but simple. My usual disclaimer applies: some of the information below is a result solely of my own experiences in trying to upgrade our organization. If there are any errors, please comment and let me know.

MSI vs. Click-To-Run

Prior versions of the Office Suite used the well-known MSI format. MSI allows the use of Group Policy for network installs, and most large organizations have plenty of experience with the format. So of course Microsoft had to fix something that wasn’t broken.

Office Pro Plus 365 and Office 2019 (I’ll cover the differences in a moment) use Click-To-Run technology (CTR) which Microsoft touts as a “modern” deployment method.

Here’s a quick comparison of the two methods:

MSI

• Deployed via Group Policy
• Installs from local media
• Patches directly from Windows Update or through WSUS

CTR

• Deployed via the Office Deployment Tool
• Installs from local media or directly from the Internet
• Patches directly from the Internet or from a network share (not through WSUS)

There are plusses and minuses to both methods, but CTR is seemingly the future so we have no choice but to deal with it.

Product Channels

For all practical purposes, there are five variants of the current Office Suite, each of which is considered a “channel.”

• Office 365 Pro Plus Semi-Annual
• Office 365 Pro Plus Semi-Annual (Targeted)
• Office 365 Pro Plus Monthly
• Office 365 Pro Plus Monthly (Targeted)
• Office 2019

The 365 SKUs are retail, and their license is tied to an appropriate Office 365 subscription that includes the Office Suite. You can choose to get either monthly or semi-annual feature updates, while security patches are applied regularly regardless. The “targeted” channels are essentially “sneak-peeks” of upcoming changes.

Where it gets confusing is that Office 2019 is essentially nothing more than a point-in-time snapshot of Office 365 Pro Plus, that will not get any feature updates; it will receive security updates only. This version is also the only one that can be volume-licensed using KMS.

As of November 1st, the most recent O365 Pro Plus Semi-Annual channel is version 1803, Office 2019 is considered version 1808, while the O365 Pro Plus Monthly channel is 1809, and the monthly targeted channel is 1810. Each has different feature sets. See Microsoft’s update history for O365 Pro Plus for more info.

Licensing

As mentioned, any of the Pro Plus channels imply retail licensing, and they must be activated against an Office 365 account that is entitled to the appropriate applications. This is fairly straightforward in an office setting where people don’t switch computers too often, but it poses a challenge in a school or other shared computer setting. In this case, you want to use shared computer licensing, and ideally license token roaming as well.

Office 2019 implies volume licensing, either using MAK or KMS. In this sense it’s identical to prior volume-licensed versions of the Office Suite. Note your KMS server will need an update to activate Office 2019.

Installation

Whether you want to install Pro Plus or 2019, and regardless of the desired channel, you will need to use the Office Deployment Tool (ODT). Essentially you will need to create an XML file that defines various options, including the desired channel, the installation source, and the update method. Microsoft’s documentation is actually pretty thorough, so you shouldn’t run into too many problems. There are a few caveats though:

• The setup.exe that you run to install the suite is actually just a stub installer. In some cases (and I haven’t yet figured out the specifics), setup.exe will terminate successfully before the apps are installed. There is a further installer that will continue to run in the background.
• The XML file gives you an option to remove any MSI-installed versions found. In my testing, this setting is ignored and the installer will always remove any older versions of Office. Even better, it will remove applications like Visio or Project that aren’t part of the suite and are thus not going to get reinstalled.
  
• Normally, the suite is going to be configured to take updates directly from Microsoft. You can no longer use WSUS to patch Office. You can technically control patches by disabling updates from the Internet and then manually downloading them to a network share, but that’s likely impractical. Realistically administrators have no choice but to accept giving up control of Office patches if they want to stay reasonably current. As an example of how little control we now have over the patch process, I left Word open with this document being edited on Friday, running version 1809. I came in Monday morning to the document still open, with Word running version 1810.

Co-Existence With Visio or Project

While neither Visio nor Project are included in the O365 Pro Plus suite, or in Office 2019, they are considered part of Office and the ODT is used to install them as well. This has implications for installing either application alongside the Office Suite. Microsoft has a KB article about that here, but it’s missing one critical bit of info.

According to Microsoft, it is possible to install Office 365 Pro Plus with a retail (subscription-based) license alongside Project 2019 or Visio 2019 using a volume license. However in the “additional information” section of the linked article, Microsoft adds a major restriction: all installed Office applications must be using the same update channel.

The reality is that restriction precludes using O365 Pro Plus along with volume-licensed copies of Project or Visio, because the retail versions use one set of update channels, and the volume license versions use a different one. Perhaps I’m missing something here but I could not get retail O365 Pro Plus to work properly alongside volume licensed (either MAK or KMS) versions of Project or Visio.

If a volume-licensed edition of Project 2019 or Visio 2019 is already installed, the O365 Pro Plus install may succeed (it did for me), however none of the applications will activate. The volume-license apps generate an error that the license has changed, and the retail apps simply refuse to license with a generic error.

If O365 Pro Plus is installed first, the volume license versions will refuse to install due to the unavoidable channel mismatch.

If you install the retail versions of Project or Visio alongside O365 Pro Plus, you cannot activate them using KMS or MAK because only the volume license version supports volume activation.

So the long and short of it is that if you need either Project or Visio, you either have to use Office 2019 and the volume license edition of Project or Visio, or you need an O365 subscription that includes rights to all applicable products.

In Conclusion

Anytime a long-standing technology changes, there are growing pains. We’re still too new to using CTR to see any clear advantages, but the move itself isn’t all that painful. However, the changes to how applications are updated, licensing, and the restrictions on product coexistence all have significant implications to cost, both in dollars and labor.

Most corporations will probably be content to stay with the volume-license editions of Office, but in education, Microsoft continues to add – and quickly publicize – new features that are only available in the monthly retail channel. So while we have the option of staying volume-licensed, the reality is we would be doing our students a disservice by not offering the latest features. And that means dealing with all the accompanying quirks.

802.1x Certificate Based Authentication against NPS on Windows Server 2016

When we were preparing to upgrade our domain controllers from 2008 R2 to 2016, we of course began inventorying all functions that were going to be migrated. One of these was Network Policy Server (NPS). NPS is one of the easiest services to migrate to a new system, since it’s basically a simple backup and restore, and we weren’t expecting any difficulties. Of course had things gone smoothly, this post wouldn’t exist.

A little background:

We use NPS for multiple functions, including Cisco AAA and wireless device authentication. Our Meraki wireless infrastructure has multiple SSIDs, some of which are for domain-joined devices, and others for non-domain devices. The domain-joined devices use 802.1x certificate-based authentication and the non-domain joined devices use various other methods.

NPS was migrated from 2008 R2 to 2016 and everything other than the 802.1x certificate authentication worked. The 2016 servers were correctly setup as RAS servers and had certificates that were valid for client & server authentication, as needed. I spent quite a long time troubleshooting this with no success, and eventually had to back-burner it. The 2008 R2 servers were due to be retired, so as a temporary measure I migrated NPS to a couple 2012 R2 servers, all of which worked flawlessly after about two minutes worth of effort.

This was pretty early in 2016’s lifecycle, so since it worked in 2008 R2 and 2012 R2, we chalked it up to a bug in the OS and intended to pursue it with Microsoft at a later date.

Before I had a chance to call Microsoft, another project had us looking at our PKI configuration. We were having issues using LDAPS with this particular system (despite using it elsewhere), and after extensive troubleshooting the vendor told us they thought the hash algorithm used by our PKI was unsupported.

Our PKI was originally setup on a 2003 server back when that was the current server OS. It had been migrated to a newer server since then but the hash algorithm had never been changed; it was still using md5RSA. Now upgrading the hash algorithm isn’t something to be taken lightly, as it can break a lot of things, but in our case since our PKI is pretty simple I decided (after backing everything up) that the upgrade risk was minimal. I changed the hash algorithm to SHA256, reissued RAS certificates to the NPS servers and just like that things started working.

I can’t find any changelog indicating why NPS would not work with an older certificate hash on 2016 but empirical evidence shows the hash was the problem.

There are plenty of resources about upgrading your root CA’s hash algorithm, but this is a good start from Jason Bender at Microsoft.

Managing Mail-Enabled Security Groups in O365

Office 365 certainly has its plusses and minuses, and one of the areas that clearly falls in the latter category is how O365 handles mail-enabled security groups.

Consider the following scenario:

• You have an on-premise Active Directory sync’d to O365/Azure via ADSync.
• You have an on-premise security group that you mail-enable, creating an e-mail address @yourdomain.com.
• This mail-enabled group syncs to O365, and then exists in Exchange Online.
• You then mail-disable the group on-premise and wait for the change to sync to Exchange Online.

Logic would dictate that once the mail-enabled attribute was removed from the group, it would disappear from Exchange Online. Of course it’s not that simple.

What you will instead find is that the security group still shows in Exchange Online, however it now has a proxy address @yourdomain.onmicrosoft.com. It will also continue to be visible in both the online and offline address books. If you are trying to move groups to the cloud and/or cleanup your distribution lists, this can cause confusion.

The fix fortunately is easy, but it’s an extra step that shouldn’t be necessary IMO. Credit to Tim McMichael’s TechNet post for the details.

The process to properly remove a mail-enabled security group from Exchange Online is as follows:

• On-Premise, remove the mail-enabled attribute from the group using the Disable-DistributionGroup PowerShell command.
• On Exchange Online, find the group via Get-MsolGroup –SearchString “Group Name”.
• Once you’ve confirmed you have the right group, remove it via Get-MsolGroup –SearchString “Group Name” | Remove-MsolGroup

This will finally remove it from Exchange Online and your address books.

EDIT: There is a major caveat here to be aware of. If you are using mail-enabled security groups to grant permissions to shared calendars, you CANNOT remove the mail attributes or you will break access permissions. In that situation I would advise simply hiding the list from the address book.

Monitoring Microsoft NLB with PowerShell

Recently the need arose to monitor the status of a Microsoft NLB cluster. There are a number of ways of approaching this, but PowerShell seemed like the cleanest.

I found this script on TechNet but found that it did not work in our (2008 R2) environment. During troubleshooting, what I found was that instead of returning a single status result, the WMI query was returning an array of results for each server. It appears that the statuscode is only relevant for the specific hostpriority applicable to each server.

For instance, this is the server with hostpriority 1 as shown in the NLB Manager:

And this is the one with hostpriority 2:

As you can see, a proper statuscode is only returned for the current hostpriority for each server.

With that in mind I made a change to the script to enumerate through the array of results for each server and check the status accordingly. This has only been tested on ADFS 2.0 on 2008 R2 servers, and it would need to be revised if you have more than two servers in a NLB cluster.

#Define Nodes
$node1 = "SERVER01"
$node2 = "SERVER02"

#get NLB status on NLB Nodes
$Node1status = Get-WmiObject -Class MicrosoftNLB_Node -computername $node1 -namespace root\MicrosoftNLB | Select-Object __Server, statuscode, status, hostpriority
$Node2status = Get-WmiObject -Class MicrosoftNLB_Node -computername $node2 -namespace root\MicrosoftNLB | Select-Object __Server, statuscode, status, hostpriority

$node1converged = $false

Foreach ($status in $Node1status)
{
if(($status.hostpriority -eq "1" -and $status.statuscode -eq "1008") -or ($status.hostpriority -eq "2" -and $status.statuscode -eq "1007"))
{
$node1converged = $true
write-host "NLB Status of $node1 is: Converged"
}
}

Foreach ($status in $Node2status)
{
if(($status.hostpriority -eq "1" -and $status.statuscode -eq "1008") -or ($status.hostpriority -eq "2" -and $status.statuscode -eq "1007"))
{
$node2converged = $true
write-host "NLB Status of $node2 is: Converged"
}
}

Sorry about the indents; they show up in the WordPress editor but not on the actual page.

Let me know if you find this useful, or if you are able to use it on a platform other than 2008 R2.