Microsoft

Updating the Country Field in Active Directory

Wanting to have all users to have the country ‘Australia’ in Active Directory, I thought it would be a simple PowerShell command. Get all the users you want and set a field to ‘Australia’. However, it’s more complicated than that.

As you can see from the above, the Country/region field is a dropdown, where you can select the country. If you look in PowerShell using ‘get-aduser username -properties *’, there’s 4 fields that get populated with this setting:

c : AU
co : Australia
Country : AU
countrycode: 36

Trying to just change one of these fields will result in an error such as:

Set-ADUser : A positional parameter cannot be found that accepts argument ‘Au’.
Set-ADUser : A positional parameter cannot be found that accepts argument ‘Australia’.
Set-ADUser : A value for the attribute was not in the acceptable range of values

The answer is that all fields need to be set at the same time. The C and Country fields are based on ISO 3166 codes, with Australia being AU and 36.

The resulting command would end up being:

set-aduser adam.fowler -Replace @{c="AU";co="Australia";countrycode=36}

Of course this can be done on a boarder scale by using ‘get-user’ with a larger scope, and piping that into the set-aduser command:

get-aduser -filter "company -eq 'Contoso'" | foreach {set-aduser $_ -Replace @{c="AU";co="Australia";countrycode=36}}

That’s all that’s required to change the field.

Hide Edge Button from IE11 Tab

A feature that’s popped up in IE11, is the little Edge icon next to the new tab icon. Not something I’d want in the enterprise space:

Thankfully, it’s easy to disable. There’s a group policy policy called “Hide the button (next to the New Tab button) that opens Microsoft Edge” which can be found in User Configuration\Administrative Templates\Windows Components/Internet Explorer\Internet Settings\Advanced Settings\Browsing\ . 

If you can’t see this policy, make sure you have the latest ADMX files from Microsoft – Windows 10 1703. If you haven’t had much to do with adding ADMX files to your environment before – they should be centralised, and Microsoft have a great guide you can follow.

Bonus tip – If you have internal sites that use a single word (e.g. intranet) you can enable the policy “Go to an intranet site for a one-word entry in the Address bar” which will check for an internal site starting with that name before using the word in your default search engine. This one’s actually an old policy that I hadn’t noticed before!

 

Checking CSV Against Active Directory Users

I’ve written before on how to update Active Directory from a CSV. This time, I’ve got a CSV list of users that I want to check are valid users against my Active Directory (AD) environment.

There’s a huge amount of ways this can be done, and this is just one of them. If you have others, or ways to improve this I’m always keen to hear!

This script assumes you have a CSV file with the header (first line) with the word ‘users’. Here’s an example CSV file: myusers.csv

Below is the PowerShell script I wrote. I’ve also written about ‘If’ and ‘Else’ before, so read that if you want some clarification. The user list I have is based on User Principal Name (UPN) rather than just username, so I’m searching AD to see if there’s a match or not.

Import-Module ActiveDirectory

$Data = Import-Csv myusers.csv

foreach ($user in $data){
$upn = $users.user
$check = $(try {get-aduser -filter "userprincipalname -eq '$upn'"} catch {$null})
if ($check -ne $null) { }
else { "$upn Doesn't Exist" }
}

What I’m doing here is setting each line of the CSV as the $UPN variable to search for. Then using the ‘Try‘ function, I’m catching if there is no result/match (null). If there’s a match, it won’t equal null, so display nothing. Else, show the UPN via the $UPN variable and follow that with ‘Doesn’t Exit’.

This way, I will only get results back from each AD search where the UPN in the CSV doesn’t match a user’s UPN in my AD environment – and I get to see what those results are.

This script method can be applied in many different ways of course, but it was the first time I’d used the Try function, and it worked really well.

 

Zero-click Single Sign-On Without ADFS

Login prompts to websites are a pain. Enterprise employees these days expect to have a single sign-on experience (meaning the same username/password everywhere) and a minimal amount of logging in to systems each day.

It’s a very different from years ago where every system had it’s own unique login, and users got into the habit of synchronizing password changes when the regular password expiries hit (and I’m sure some companies still run this way), but it’s a problem IT as a whole has worked on for many years.

Microsoft has had a big focus in identity management for many years, with products such as FIM/MIM and ADFS along with the old faithful Active Directory, controlling and giving framework for authentication. The on-premises approach didn’t work for cloud based technologies though. Going to a site such as Office365.com will show an area to sign in:

 

Going back to the requirements of getting logged out of sites, or needing to log into each different Microsoft service is a pain and time sink for users. The original answer to this problem was ADFS. This works well, but requires the ADFS infrastructure to be set up, and needs to be highly available. If ADFS goes down, your users can no longer authenticate to Azure AD, which is what powers the identity management and authentication orchestration for Microsoft enterprise users (this includes Office 365).

More recently, another native solution was released – Pass Through Authentication for Azure AD Connect (Azure AD Connect being the service that syncs your on premises AD to Azure AD). This removes the requirement for entering a password to these Microsoft services which is great for users, but still requires the entry of the username (which in Azure AD, is the User Principal Name, and looks the same as an email address to confuse things more for users). It’s a good start, but still not the seamless authentication many users expect.

There is another way of providing zero-touch logins to Microsoft services without ADFS, which is Azure AD Domain Join. Windows 10 is a requirement here, but beyond that, the setup is quite easy if you’re already configured for Azure AD. Maurice Daly has written a great guide on this, which outlines all the requirements and steps to follow to be up and running. (Thanks Maurice for your help on this!)

Gotcha for myself: I found that I had an old version of the Microsoft Azure Active Directory Module for Windows PowerShell which didn’t have the get-msoldevice cmdlet at all, and had to download an updated version. I also updated the AzureRM module for good measure since it was also out of date, but shouldn’t have been a requirement.

This is a rather complex topic, so I’ve tried to give a fly-over view of the native options available. There’s also Smart Links which can speed up and improve the user experience.

If you’re on Azure AD and Windows 10, give Azure AD Domain Join a try. It may save you the hassle of building and maintaining an ADFS server, and give your users a better experience overall.

Viewing Mbox Files On Windows

A MBOX file is similar to a PST file, in that it contains a collection of emails. PSTs will be familiar to those of us in the Windows world, as it’s one of the old formats Outlook will use.

(Side note: PSTs are bad, but they do function well as a way of transporting a large chunk of mail from one place to another).

MBOX is the Unix version of PSTs. Google also uses this for Gmail, so if you run an export job, you’ll end up with a MBOX file. Microsoft Outlook doesn’t support this format though – so if you’re sent one, how do you view the contents?

If you start Googling, you’ll come across a bunch of ‘free’ viewers and converters. Most of these are free in the demo sense, and will only view or covert 20ish emails.

I eventually found these two free solutions and tested that they worked; if you find any others feel free to share.

 

Windows Mbox Viewer

This is a free, open source viewer of MBOX files. There’s no installer, just launch the exe, open your MBOX file and you’ll get a simple list of emails and can view the contents. Beyond being able to do searches, the program doesn’t do anything else. This is a great, simple solution if you just want to view the contents of the MBOX file. If you have Outlook installed, double clicking on an email will open it in Outlook, which can then be saved/printed.

Thunderbird

This is also completely free, from Mozilla. Here is a great set of instructions on how to configure Thunderbird to be able to read your MBOX file, but there’s a few more steps involved. Once Thunderbird can see them, you have a lot more options. The emails can be synced to another mail server, or you can simply select emails and save them out. They’ll be saved in the EML format, which Outlook will then recognise. More information about importing and exporting is available here.

 

I never found completely free software to convert from MBOX to PST, so if you really need that functionality, it might be time to take out the credit card and pay a hard working developer!

Azure AD B2B PowerShell Invites

I’ve written about Azure AD B2B before, as well as then giving those invited users access to SharePoint Online, but there’s been a lot of changes since I started using it. Have a read of my original article if you’re interested to see how I’m using B2B and why.

Azure AD B2B is still in preview, but in Feb 2017 a bunch of improvements were added. Part of these changes were around using the new Azure portal rather than the Classic Portal, and with that is the removal of inviting users via CSV file and uploading it to Azure AD. This was exactly the way I was using it, so I had to change to one of the newer methods.

Although CSV support is gone, it’s been replaced by PowerShell which can just call the same CSV file being used before, so it’s not a huge change. There’s a PowerShell example on this technet page which shows how to do it. There is a catch though, the ability to add the user to groups as part of the import is gone.

The other big change that impacted me was the invitation emails. This is the email that gets sent to the recipient when being invited – it was originally a plain text email from a generic Microsoft address, but it’s now changed to a much more professional looking email. The catch with this is, rather than coming from a generic Microsoft email account, it now comes from the user that sends the invites out. I found this out the hard way when invited parties started seeing my details and photo with the invite!

There’s four approaches I can come up with around this new invite method –

1. Leave it as showing the admin user who does the invites (not ideal)

2. Create and use a seperate service account for these invites, so it comes from a generic looking internal email address (quite good)

3. Get the users themselves to send the invites out – by default, all users have access to invite others to their tenant (worst option, users won’t do this themselves, need training and support, can’t automate)

4. Use APIs and send the invites out on behalf of the user (‘best’ option but requires the most work, most complex)

While I look at option 4, option 2 is a good middle ground and will probably do for most companies.

I’ve written and tested the below script, which works on a single user by user basis. This uses just the Azure AD Preview module for PowerShell, which is at version 2.0.0.85 at the time of writing. To use the method mentioned on that page to install, I had to first install Windows Management Framework 5.0.

$group = get-azureadgroup -SearchString "Put your exact search string here" | where {$_.dirsyncenabled -eq $null}
$newuser = New-AzureADMSInvitation -InvitedUserEmailAddress emailaddress@contoso.com -InvitedUserDisplayName "Full Name" -sendinvitationmessage $true -InviteRedirectUrl "http://myapps.microsoft.com"
Add-AzureADGroupMember -objectid $group.objectid -RefObjectId $newuser.InvitedUser.Id

 

This script requires you to first authenticate against Azure AD with the command connect-azuread : the same way you’d use connect-msol for Office 365. More on how to automate that part in an upcoming blog post.

I’ve written this on the basis that you already have a group to add the guest user into, which gives them the permissions required after being invited into your Azure AD tenant. It’s also more a proof of concept script, which shows how to automate these steps enough to then be able to do what you want with it – such as wrap it around a ‘for each’ and feed multiple users into it.

The first thing the script does is get the group name. As objects in Azure AD don’t have to have unique names like on-prem Active Directory, this script will fail if it finds multiple results the same. It’s also making sure the result that comes back is only a cloud based group, because you can only add B2B invited users into Azure AD groups (not ones synced from on-prem).

Next it will send out the invite to the user. This is the important part. If you don’t want an email to go out, you can change the -sendinvitationmessage value to $false.

Finally we’re adding the invited user into the group by ObjectIDs of each object – straight forward.

—-

The end result is a user who will be able to accept their invite, log in and have access to whatever they need to. Note that the way I do this is by having an app and advertising it to the group that also gives permissions to SharePoint Online, so they’ll see the single link on their myapps.microsoft.com page.

If you’re mucking about with Azure AD B2B this should give you somewhere to start. The Microsoft Technet pages for Azure AD are very comprehensive now as well as being easy to read, so check them out.

If you have any questions on Azure AD B2B feel free to ask!

Azure AD Group-Based License Management For Office 365

It’s finally here! At least in public preview…

The ability to allocate Office 365 licenses via groups is now available for everyone to use. This has been a long-awaited feature, up until now licenses have either been applied manually via the portal, or via scripts/3rd party software with logic applied for automation.

Now, you can automatically apply and manage license allocation using whatever logic you like. You can create on-premise AD groups, apply a license set to the groups, and members will be allocated the relevant licensing. If that doesn’t work for you, there’s also cloud based Dynamic Groups which let you use whatever logic you can come up with to add members to the group. You could do it on something like a department name, or use an extension attribute and populate that based on what license you want to allocate.

The above link covers a lot of information about how to deploy this. At the time of writing, I couldn’t get to the Azure Licensing page by searching for the word ‘Licensing’, and instead had to use a direct link: https://portal.azure.com/#blade/Microsoft_AAD_IAM/LicensesMenuBlade/Products

I’ve already deployed it, it seems to work quickly and without issue.

 

Once you’re done, you’ll need to remove the Office 365 licenses applied manually. This TechNet article shows the commands to use for removal. I used this:

$Users = Get-MsolUser -All | where {$_.isLicensed -eq $true}; $Users | foreach {Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -RemoveLicenses "litwareinc:ENTERPRISEPACK"}

This removes licenses from all your users, to be more specific add extra criteria to the first ‘Get-MsolUser’ command. Also note you need to swap ‘litwareinc’ with your tenant ID, and ENTERPRISEPACK with whichever license you’re removing. I’d recommend testing on one account first!

To see what your tenant’s license options are just use:

Get-MsolAccountSku

And you’ll see a list of the license options along with existing allocations.

If you have any questions please comment below.