ADFS

All posts tagged ADFS

Monitoring Microsoft NLB with PowerShell

Posted by James F. Prudente on June 21, 2018
Posted in: Active Directory, ADFS, PowerShell, Windows Server. Tagged: , , , . Leave a comment

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.

Fixing Missing Address Book Entries in O365

Posted by James F. Prudente on October 6, 2014
Posted in: Active Directory, Exchange, Office 365, Windows Server. Tagged: , , , . Leave a comment

Recently I’ve been working to get a full O365 implementation setup to roll-out to our students, and while we’re not doing student e-mail just yet, I wanted to make sure everything is working so when we are ready, we just have to add the Exchange licenses. One of the quirks I ran into is a few users were not listed in the Office 365 address book. We do not have a hybrid Exchange deployment, but because our AD is sync’d to O365, we should have a full GAL in the cloud accessible to be searched by any Office 365 user.

After going through the usual online search and not turning up anything too helpful, I decided to compare O365 data for two users: one who was showing up in the GAL, and another that was not. I piped the output from Get-MSOLUser to a separate text file for each user, then used WinMerge to compare them.

Get-MSOLUser –UserPrincipalName UPN1 | fl > user1.txt

Get-MSOLUser –UserPrincipalName UPN2 | fl > user2.txt

The one attribute that stood out as different was CloudExchangeRecipientDisplayType, which was set to “-2147483642” for the user that was in the GAL, and “1073741824” for the user that was not. I started researching that attribute and found this very helpful post. The poster of that Article, Declan Conroy, was trying to trick O365 in such a way as to facilitate an easier migration from on-premise Exchange to the cloud. It wasn’t an exact fit for my situation, but it did make clear that “CloudExchangeRecipientDisplayType is not available as an attribute in AD, [but] is exported…with the value from the incoming msExchRecipientDisplayType attribute.”

That led me to look for more info on msExchRecipientDisplayType, and I found this page listing the meaning of the various values for both that attribute and msExchRecipientTypeDetails.

At this point it still wasn’t clear to me if the discrepancy in CloudExchangeRecipientDisplayType was causing the missing GAL entry, and because the only way to change that attribute in the cloud was to change msExchangeRecipientDisplayType in my local AD, I wanted to investigate more.

I decided to search for other users with 1073741824 as their CloudExchangeRecipientDisplayType:

    Get-MSOLUser | Where-Object {$_.CloudExchangeRecipientDisplayType -eq 1073741824}

The results from this search seem to confirm that this is the expected value for users who do not have on-premise mailboxes.

Some more digging turned up another disparity between accounts in the GAL and those that were not. I ran this command:

    Get-User –Identity displayname | select RecipientType, RecipientTypeDetails

I found three distinct results:

RecipientType

  

User

These recipients were not in the GAL

MailUser

User with on-premise mailbox, in GAL

UserMailbox

User with O365 mailbox, in GAL

 

This provided further evidence that the incorrect CloudExchangeRecipientDisplayType, which was controlled by the on-premise msExchRecipientDisplayType attribute, was the source of the problem. So now to fix it…fortunately I had already found the answer in a post I linked earlier.

Using the attribute editor in Active Directory Users & Computers I made three changes to each affected AD account:

Attribute

Change To

msExchRecipientDisplayType

6

msExchRecipientTypeDetails

128

targetAddress

User’s e-mail address

 

Note that to access the attribute editor you must have advanced features enabled, and for some reason that tab does not show if you perform a search for the user. You’ll need to manually find them in AD and pull up their properties there instead.

You then need to perform a sync of your on-premise AD to the cloud. After doing so, RecipientType and RecipientTypeDetails both showed “MailUser,” and CloudExchangeRecipientDisplayType showed “-2147483642,” both of which were expected values for a working on-premise mailbox. A quick check of the address book showed the users were now listed in the O365 GAL.

You’re still not done though. If you leave the settings like this you will break your on-premise mailbox. (Why is it you only discover this stuff late on a Friday night, when you’re trying to relax?) You must change msExchRecipientDisplayType, msExchRecipientTypeDetails, and most importantly targetAddress back to their original values (1073741824, 1, and not set, respectively) in your on-premise AD. This will keep your mailbox working but the change to the cloud user type will remain. All set!

In speaking with a colleague recently I remarked that 90% of what you do in Office 365 is easy and works well, but the other 10% is a real source of pain. As we’ve seen here, much of that 10% comes from the fact that it’s not clear what many O365 attributes represent, and even when it is, those attributes are often not directly editable by administrators. Hopefully that situation will improve in time.

Configuring Office 365 for Students

Posted by James F. Prudente on September 30, 2014
Posted in: Office 365. Tagged: , . 4 Comments

Microsoft offers certain K-12 school districts Office 365 licenses for students and faculty at no charge. This includes online versions of the Office suite, Exchange online, 1TB of OneDrive storage, SharePoint, Yammer and Lync. If one were starting from scratch you could pretty much use Office 365 for your entire storage and messaging infrastructure with no cost. Of course, most of us are not in that position and are already running some of these services on-premise, possibly with others in the cloud.

In our case, while we are using Office 365 for Yammer and as our back-end for Lync, we have Exchange on-premise for staff. We wanted to use Office 365 for student e-mail, but while we’re on Exchange 2013 and thus could support a hybrid deployment, we felt that was introducing unnecessary complexities. We also had no interest in touching our existing, fully-functional e-mail system.

We elected to purchase a new domain for our students, so the challenge became getting that domain up and running with our existing Office 365 setup, including ADSync and Single-Sign-On via ADFS. This post addresses how we went about doing so. It will be light in details in certain areas but hopefully help with the more complicated steps.

To start, you’ll need to purchase the new domain; we went with something that clearly identified these users as students. Once that’s done, add it to your Office 365 setup. You’ll need to have specific DNS entries added to validate your ownership of the domain, then setup the proper MX and related records.

Next, you will need to add a new UPN suffix (matching the new domain) to your on-premise Active Directory.

All users who will be using that new domain need to have their UPN suffix changed in your on-premise AD. This can be scripted through VBScript (which is what we used) or PowerShell.

Now you’ll need to re-sync your whole AD to the cloud so that the change to the UPNs take place, but there’s one important caveat: If your users already have a federated domain as their UPN, you cannot change their UPN directly from one federated domain to another federated domain. This isn’t clear from any documentation I could find, and the sync will complete successfully with the only indication of a problem being one warning, from FIMSynchronizationService, eventID 6105:

“The management agent “TargetWebService” step execution completed…but some objects had exported changes that were not confirmed on import.”

After a lot of unnecessary (and unproductive) troubleshooting, I stumbled on this post on the Office 365 community which points to the solution: change the UPN of any affected users back to the default “domain.onmicrosoft.com” suffix, sync your on-premise AD to the cloud, the change the UPN a second time to the new desired federated domain suffix, and finally sync one last time.

With that resolved, if you are using ADFS for SSO, you’ll need to update it to account for the new domain. A default installation of ADFS 2.0 does not support multiple top-level domains; you’ll receive the error “…federation service identifier specified…is already in use.” This can be fixed relatively easily by following MS KB #2618887. I was worried about this step but it took all of two minutes and did not cause any issues at all.

At this point, if everything is setup properly you should be able to use SSO to access Office 365 with valid credentials from any of your federated top-level domains. Now you’ll want to bulk license Office 365 users.

There are a few parts to bulk licensing. Before you can do any of this you need to connect to Office 365 using the Microsoft Online Services Module for PowerShell. Enter your administrator credentials for Office 365 when prompted.

$cred = Get-Credential            

Connect-MSOLService –Credential $cred

The first thing we need to do is set a location for our users. Note “US” must be capitalized, and obviously if you’re not in the US, you’ll need to substitute the proper country code. We’re only touching the unlicensed users here since you probably have users that are already setup, and the –All parameter is important so the results are not truncated.

Get-MsolUser -UnlicensedUsersOnly -All | Set-MsolUser -UsageLocation US

Now we need to figure out what licensing we want to assign. Your results may differ depending on what you may have purchased.

Get-MSOLAccountSku | select AccountSkuID


ECAL_SERVICES_FACULTY Exchange Archiving, Exchange Online Protection
OFFICESUBSCRIPTION_STUDENT Office Pro Plus Licensing for Students
STANDARDWOFFPACK_FACULTY Office 365 A2 License – Faculty
STANDARDWOFFPACK_FACULTY Office 365 A2 License – Students

This will list the different licensing packages available to you, but most likely you’ll want further detail. For each AccountSkuId shown you can run the below command to see the individual products and services. (Substitute whichever SKU you want for ‘STANDARDWOFFPACK_STUDENT’ below.)

Get-MsolAccountSku | Where-Object {$_.SkuPartNumber -eq ‘STANDARDWOFFPACK_STUDENT’} | ForEach-Object {$_.ServiceStatus}

These are the specific products and services that can be licensed under the top level SKU.

EXCHANGE_S_STANDARD Exchange Online
MCOSTANDARD Lync
SHAREPOINTWAC_EDU
SHAREPOINTSTANDARD_EDU		 SharePoint and OneDrive for Business (Must be licensed together.)
YAMMER_EDU Yammer (does not require explicit licensing)

If you want to selectively enable portions of the SKU, you need to license the SKU and disable the services you do not want. We do that by setting Licensing Options. In this example we are disabling Lync and Exchange. Note you’ll need to use the full AccountSkuId (including the prefix) in the command below.

$options = New-MSOLLicenseOptions -AccountSkuId organization:STANDARDWOFFPACK_STUDENT -DisabledPlans MCOSTANDARD,EXCHANGE_S_STANDARD

You then assign the license with Set-MSOLUserLicense, but to do this in bulk we have to first filter the users to whom we want to assign licenses. In this case we’re assigning student licenses to users with the student domain we setup earlier, then we will pipe that output to the Set-MSOLUserLicense command. Note “studentdomain” is the domain suffix you’ve setup explicitly for these users, and does NOT include the “@” symbol. (We’re splitting the UPN at the “@” and taking only the part to its right.)

    Get-MSOLUser -All -UnlicensedUsersOnly | Where-Object { $_.userPrincipalName.Split(“@”)[1] -eq “studentdomain” }

Incidentally if you want to get a count of those users, you can enclose the entire command in parenthesis and append .count to the end. i.e. (command).count

The above command will only show the impacted users. To actually assign licenses we need to pipe this output to Set-MSOLUserLicense as follows:

Get-MSOLUser -All -UnlicensedUsersOnly | Where-Object { $_.userPrincipalName.Split(“@”)[1] -eq “studentdomain” } | Set-MsolUserLicense -AddLicense organization:STANDARDWOFFPACK_STUDENT -LicenseOptions $options

You can repeat that command if you need to assign additional licenses (for instance, the Office subscription) but keep in mind you’ll have to remove –UnlicensedUsersOnly since these users are now licensed. We also found adding the second license generated a lot of errors about the license being invalid, but given enough time everything did completely successfully and all of our users were licensed properly.

The overall process is a little tedious, but when you consider what Microsoft is giving away for free, it’s well worth the trouble. Hopefully this posts makes things a bit easier.