Restrict OneDrive for Business synchronisation to domain joined machines only

Edit: This can now be done in a GUI by using the OneDrive Admin Centre at admin.onedrive.com. It also allows Mac clients by default now.

A quick preface to this post; making the changes listed below will stop all Mac clients from being able to sync their OneDrive, and will not stop mobile devices from connecting to OneDrive using the app. It also doesn’t stop the downloading or uploading of files from the web access of OneDrive. It’s sole purpose is to limit the functionality of the Windows OneDrive for Business sync client!

Firstly you need to find out the GUID for the Active Directory domain which you want to be able to sync OneDrive for Business from. To do this, log onto a Domain Controller and run the Active Directory Module for PowerShell, or run a normal PowerShell window and run

import-module ActiveDirectory

in order to get the correct cmdlets imported. Get a list of your domains by running

(Get-ADForest).Domains

And then use this command to get a list of GUIDs which will be in the same order as your domain list

$domains = (Get-ADForest).Domains; foreach($d in $domains) {Get-ADDomain -Identity $d | Select ObjectGuid}

From this you should be able to work out the correct GUID for your Active Directory domain name. Copy and paste that sucker into notepad. Now head on over to a SharePoint Online PowerShell session using the SharePoint Online Powershell module and Connect-SPOService and run

Set-SPOTenantSyncClientRestriction  -Enable -DomainGuids "b45b7d67-e68b-430e-bb76-2a31948b3221”

Make sure you replace the GUID here with the GUID you copied and pasted earlier and this setting will lock down your OneDrive for Business synchronisation to client which have the same domain GUID. If you want to enter more than one GUID, separate them with commas.

Hope this helps and sorry if it’s a bit of a haphazard blog post, it was written in a bit of a hurry!

Advertisements

Disable Clutter feature for all users in Office 365

DisableClutter

Now I’m not one to advocate turning features off in Office 365, but sometimes when deploying Office 365 for a customer, there is simply too much change at one time. And if there is one thing that users hate, it is too much change!

Many customers I work with will choose to disable Skype for Business or OneDrive during the initial migration of email into the cloud. They can then plan the roll out of these services at a later date, and educate users on how to make the best use of it. This is much more preferable to just throwing a load of new functionality at users and expecting them to just start using it all with no training. After all, adoption of new technology starts with giving users the knowledge and power to be able to use the tools effectively!

And on that subject is a feature which has baffled and confused some users. This is called ‘Clutter’, and it uses machine learning to help organise the email which you don’t look at regularly, but may not want to delete (for example, that weekly newsletter from exchangeserverpro.com). This mail is automatically moved into your Clutter folder, clearing up your inbox so that it contains the email you need to know about now!

Email which is automatically moved out of your inbox does have the ability to freak users out if they aren’t expecting it, so you may want to disable this at first and then enable once you can communicate it’s purpose and usefulness to the business. To do this, you will need to make use of the mighty PowerShell!

Log yourself into Exchange Online PowerShell and use the following commands depending on your needs:

To disable Clutter for a single user:

Set-Clutter -Identity user@domain.com -Enable $false

To disable Clutter for all users:

Get-Mailbox | Set-Clutter -Enable $false

This command has a long list of outputs. If you want to hide the outputs, just add > $null to the end of the command, like this:

Get-Mailbox | Set-Clutter -Enable $false > $null

You can check to see if a mailbox has Clutter enabled by running:

Get-Clutter -Identity MailboxID | fl

And look for the IsEnabled parameter, which should be set to False!

So in summary, feel free to turn it off, but whatever you do, make sure you turn it on again as Clutter is definitely a useful tool to have in your email armoury!

Azure Active Directory Sync – AAD Connect Disaster Recovery and High Availability

I just wanted to write and tell you all about a fantastic new feature built into the AAD Connect tool. It’s name is ‘Staging Mode’ and it has a dual purpose; a) it allows you to have a server which is essentially on standby, and b) it can be used just as it’s name suggests, in a kind of test mode where you can see what is being imported before it all gets sent off to Azure AD.

In real life it would be utilised thus:

Customer A has a functional installation of AAD Sync / AAD Connect which is synchronising objects and attributes between Azure Active Directory and the On Premise Active Directory. They then build an AAD Connect server in their DR datacentre (or wherever they fancy), and during the initial configuration, enable ‘Staging Mode’. Apart from this setting, they configure it just like their existing, live AAD Sync / AAD Connect server. They even leave the scheduled task enabled and running. All of a sudden, DR strikes, and the live AAD Sync / AAD Connect server goes offline forevermore, cast into the computer graveyard in the sky. Rather than restore the server from backup, they simply log into their second AAD Connect server and disable ‘Staging Mode’. This server then starts synchronising with Azure Active Directory in earnest, without having to miss a beat.

What Staging Mode does is very simple. It acts just like a functional AAD Connect installation, except for the fact that it exports nothing to Azure Active Directory or your on premise Active Directory. It also does not perform any password sync or password write-back functions. The metaverse is fully populated and ready to start exporting data, giving you the easiest possible way to have a server on standby. Unfortunately there is no replication between your two synchronisation servers, so any configuration changes need to be replicated manually, but this is another step to making AAD Connect fully HA, which is becoming much more desirable as Azure Active Directory gains traction.

AADConnect Staging Mode

ADFS 3.0 service will not start – error 1297

This issue is fairly well documented, but I wanted to put it here for my own purposes:

When installing a new ADFS farm, you may find that if you reboot the ADFS server, or restart the ADFS service, it will not restart and fails with a 1297 error code. In the Event Viewer you will see an error stating that;

A privilege that the service requires to function properly does not exist in the service account configuration

This error screams of an issue with the configuration of the service account…and that’s exactly what it is. On the affected ADFS server, open the Local Security Policy console (secpol.msc) and expand the following container:

Security Settings\Local Policies\User Rights Assignment

Go into the properties of the Generate Security Audits section and add the ADFS service account into here. If the option to add an account is grayed out, then that means that a Group Policy is controlling this access list, and you will need to find and modify the appropriate GP to add the ADFS service account into the group (usually the Default Domain Policy). While you are here, ensure that the ADFS service account has ‘Log on as a Service’ privileges.

Once this is done you should be able to start the ADFS service (although if you edited Group Policy then run gpudpdate first). Hopefully this helps you before you get to the point where you make the ADFS service account a Domain Admin! Remember, this account only needs Domain User privileges and should not be put into god mode!