Master & Cmd-R

Find which server DirSync is installed on

As consultants, we often find ourselves in environments that haven’t been properly managed, and usually not properly documented – which is generally why we get called in.

In this particular situation, I was asked to install and configure DirSync / AAD Connect for a client – only to find out that it was already installed! The funny part is that the client didn’t know it was installed, and nobody knew what server it was installed on, so I had to do some digging to find it.

Before logging in to every server and checking running services, installed programs, etc., I thought I’d take a look to see if there was a better way. Sure enough, fellow MVP Benoit Hamet suggested this answer on the Office 365 community forums. All props go to him for providing this simple solution:

“The MSOL account has a description which contains the server name on which it’s been installed”

So I checked in AD, and sure enough, this is what I found:

2015-10-16_9-43-50

And in the description?

“Account created by the Windows Azure Active Directory Sync tool with installation identifier ‘e80ac210a5e14d6095c0fcea79acc5f9’ running on computer ‘RANDOMSERVER‘ configured to synchronize to tenant ‘domain.com‘. This account must have directory replication permissions in the local Active Directory and write permission on certain attributes to enable Hybrid Deployment.”

Brilliant – thanks Benoit!

Enable OneDrive domain sync restrictions

One of the admin controls that has recently been added to OneDrive for Business is the ability to restrict file sync to only work on domain joined machines. Here’s how you enable this:

First, you need to get the domain GUID by running the following command in PowerShell:

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


Next, set the domain GUID as the only accepted domain for OneDrive sync:

Set-SPOTenantSyncClientRestriction  -Enable -DomainGuids "xxxxxxx-xxxx-415c-aa3b-9d06b595c714"

That’s really all there is to it – if you need to undo these changes and open sync back up again, simply run the following command:

Remove OneDrive domain sync restrictions:

Remove-SPOTenantSyncClientRestriction

When this feature is enabled the following will occur: (pulled directly from the TechNet article)

  • All OneDrive for Business Sync client requests originating from a domain that is not on the safe recipients list will be blocked.
  • All OneDrive for Business Mac Sync client requests will be blocked.
  • Mobile clients are not blocked when this feature is enabled.
  • Regardless whether a computer is managed by a device management solution, a sync relationship will not be established unless they are joined to a domain in the Safe Recipient List.
  • Any files that have been previously been synced down to your computer will not be deleted.
  • Please be aware the following upload behavior:
    • New or existing files added to the client will still be uploaded to the server and will not be blocked.
      • Regardless if the computer is joined to a domain which is set in the Safe Recipient List.
      • Regardless if the computer is joined to a domain which is not set in the Safe Recipient List.
      • And for all non-domain joined computers.
  • OneDrive for Business sync client prior to version 15.0.4693.1000 will stop syncing existing libraries.

 

For more information, see the following articles:
How to enumerate a domain GUID in an Active Directory forest: https://technet.microsoft.com/en-us/library/dn938435.aspx
Use Windows PowerShell cmdlets to enable OneDrive sync for domains that are on the safe recipients list: https://technet.microsoft.com/en-us/library/dn917452.aspx

Lessons Learned, SharePoint Online Edition

When you connect to as many different Office 365 tenancies as I do, it’s easy to lose track of which tenant you’re connecting to – especially if you’re working on one project, but logging on to another tenant to test changes.

Sure enough, I was testing OneDrive sync restrictions for a client, and I accidentally ran the cmdlets in their production tenant, and not in my test tenant like I thought. Basically, the purpose of the cmdlet is to only allow domains on a safe list to sync – everything else (including Macs) gets blocked.

Needless to say, I was horrified when users company-wide started reporting that their OneDrive sync had stopped working! Thankfully, I was able to reverse the changes fairly quickly, and my client took my mistake and profuse apologies in good grace.

Now, it’s one thing to call this a Lesson Learned, and say that you should always double check your tenant name before you connect to run PowerShell commands, but a good friend and colleague of mine has a saying about lessons learned that I’ve taken to heart:

“There are only three responses to lessons learned: either we need more research, give feedback to the consultant, or change the process.”

So I took my feedback like a big boy, and decided that I was going to figure out how to change my process to prevent these types of mistakes from happening again – and I re-wrote my connection script to force me to put in the tenant name every time I connected. It can’t completely prevent mistakes, but it at least prevents autodialing the wrong tenant if I’m not paying attention to what I’m doing.

Here’s what the script looks like:

param (
[Parameter(Mandatory=$true,ValueFromPipeline=$false)]
[String] $TenantName = ""
)

$spoDomain = "https://" + $TenantName
$spoDomain = $spoDomain + "-admin.sharepoint.com"
$objCreds = Get-Credential

Connect-SPOService -Url $spoDomain -credential $objCreds
Connect-MSOLService -credential $objCreds

 

And here’s a copy that you can download and use if you’d like: Connect-SharePoint-Online.ps1. Simply run this script with the -TenantName parameter, like so:

.\connect-SharePoint-Online.ps1 -TenantName Contoso

If you only ever connect to a single tenant, all you need to do is change your connection string to look like this:

$objCreds = Get-Credential
$spoDomain = "https://contoso-admin.sharepoint.com"

Connect-SPOService -Url $spoDomain -credential $objCreds
Connect-MSOLService -credential $objCreds 

This connects you to both SharePoint Online, as well as the MSOL Service so you can query / manage AD objects as well.

Hope this helps… as always, scripts or cmdlets are provided without any guarantees on my part – read it over and make sure you know what you’re running before you execute scripts in a production environment!

Force ADFS Database Sync

This’ll be a quick one – I ran into an issue last night where my secondary ADFS servers were not updating their database settings from the primary, and hadn’t updated in over 10 days. This was causing problems, as I had made some changes to ADFS to configure Yammer SSO, and the correct claims rules weren’t being applied if users hit the wrong server.

I checked the Poll Duration in PowerShell, and found that it was set to the standard 300 seconds (5 minutes), and not some insanely long interval:


I tried changing to a shorter poll interval by using the following command:

Set-AdfsSyncProperties -PollDuration 10

This drops the poll duration down to 10 seconds, so you’d think that it would update pretty quickly. Sadly, if a server is already not syncing at 5 minute intervals, setting a shorter sync still doesn’t change anything.

After looking around the web, I couldn’t find any options to force a database sync either through PowerShell, or through the GUI. Thankfully, the resolution to the problem is actually quite simple – just restart the ADFS services, and this will force the database to resync immediately.

Since I was already in PowerShell, I restarted the service using the following command:

Restart-Service adfssrv

You can, of course, just restart the service through services.msc – but I like using PowerShell whenever I can, so there you go!

OST is in use and cannot be accessed

I ran into this weird error after deploying Office 365 Pro Plus with Skype for Business – it only affected a few users, but it was incredibly annoying, and the error message was somewhat misleading:


 

Other times we’d see this error:


 

After doing a bit of research, it turned out that these errors were being caused by having two different versions of Office installed. I ran into this forum post which talks about having Office components both in the Program Files and the Program Files (x86) folder. The workstation in question had Office 2013 Pro Plus (installed from MSI), and then the standalone (Click to Run) OneDrive and Skype for Business clients installed.

I checked one of my test machines that had the Office 365 Pro Plus client installed, and all Office programs were installed by default into the C:\Program Files\Microsoft Office 15\root\office15 folder. Checking the shortcuts on the Start Menu, both Skype and Outlook ran from that folder. I found this interesting, as 32-bit software normally gets installed into the Program Files (x86) folder.

I had another test machine that had the Office Professional Plus 2013 package installed – that package includes Skype and OneDrive for Business clients, all installed in the C:\Program Files (x86)\Microsoft Office\Office15 folder.

The solution to this problem is actually quite simple – uninstall the conflicting versions of Office, and keep your installs using the same source; either Click to Run, or MSI installer. In this case, the user was supposed to have Office 2013 Pro Plus, so I uninstalled the Click to Run versions of Skype and OneDrive for Business, and the problem was solved. If necessary, you can run a repair of Office to make sure everything lines back up again, but I didn’t find this to be necessary.

Yammer user blocking

By default, any user can create an account on Yammer using their work email address and get added to your company network. Most of the time, this is just what you want – however, if you’re in a Proof of Concept, you need a way to control the size of the group who has Yammer access in order to perform your testing in a controlled manner.

Before a user can be blocked, their account needs to be deactivated in Yammer. If you export a list of users from within Yammer, all deactivated users show up as soft_delete. Active users simply show up as active. If the user hasn’t logged into Yammer at all, their account won’t show up in the list of users, but I’ll cover blocking these users below.

Deactivating Current Users:

This can be done one at a time, by typing their name into the search field on the Yammer Admin page, under Remove users:


Select the user to be deactivated, and the action you want to take, and then click Submit.


Once a user has been deactivated, they can be reactivated by simply clicking Reactivate beside their name in the list.


Deactivating Users through Bulk Update

You can also use the Bulk Update tool in Yammer to perform the following actions: create a new user, update an existing user, as well as suspend or delete a user.


The Bulk Update tool cannot be used to block or unblock users – this must be done manually through the Yammer Admin page, under Block Users.

Blocking Users in Yammer

Blocking users prevents them from creating an account on your Yammer network – this is why an active user can’t be blocked, only accounts that haven’t been activated for Yammer, or have already been deleted from within Yammer.

To block a user, simply copy paste their email address into the Block Users field – either one email address per line, or comma separated. This field doesn’t allow you to import a csv file of users, but a csv file can be used to copy/paste the required addresses into the field. Once you have the email address(es) in the field, click Block.

2016-05-05_11-18-02

When a blocked user attempts to log into Yammer directly through www.yammer.com, or by clicking on the Yammer icon in Office 365, they’ll be redirected to the following error page:


Unblocking Users in Yammer

To unblock users in Yammer, simply find their name in the list and click Unblock.


An unblocked user is immediately able to log into Yammer as normal:


As you can imagine, this process is far from ideal – it’s not that bad if you only have a few users to deactivate / block, but what if you had to do this for an organization with thousands of users? That would be incredibly painful to manage – and enabling / disabling access in the future involves scrolling through pages of blocked users to unblock them one at a time.

I really only recommend using this process for smaller networks – if you are planning on implementing Yammer, or have done so in a larger environment, Yammer Single Sign On allows you to allow / deny access based on AD security group. This is much easier to manage, and allows you to control the roll-out, rather than having to let everyone access it right away, and clean up the mess that comes out of that approach.

Creating OME Transport Rules

Once you’ve enabled Azure Rights Management in the Office 365 portal and configured your tenant, your next step is to create transport rules that will encrypt (and optionally decrypt) email messages based on the settings you choose.

Start by going to the Exchange Admin Center, and click on Mail Flow, then Rules. Click the + icon to start creating a new rule, and select Apply rights protection to messages…


Provide a name for the rule, and the initial criteria that will trigger the policy:


Next, you can select the type of RMS policy that will be assigned:


Clicking this *Select one… option allows you to choose one of the RMS templates that you’ve defined.


Or you can choose to use the built in OME option:


The difference between the two options is basically that Office 365 Message Encryption would be considered the basic policy, and choosing an RMS template allows you to specify advanced options.

The decryption option is the reverse of our first policy:


Note that the decryption option ONLY decrypts the replies to emails sent out from this organization. If another organization has their own encryption policies in place to encrypt email sent to your organization, this will not decrypt those messages automatically. The purpose of setting up this decryption is to make the process more user friendly, and seamless for users in your environment.

Tenant changes required for Office Message Encryption

When setting up Office 365 Message Encryption (OME), there are some changes to your tenant’s IRM (Information Rights Management) configuration which requires connecting to Exchange Online through Powershell.

Once connected to Exchange Online, start by checking your existing IRM Configuration by running the following command:

Get-IRMConfiguration


Note that there is no RMS Online Key Sharing Location defined, so you’ll need to perform that step next:

Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.na.aadrm.com/TenantManagement/ServicePartner.svc

Next, Import the RMS Online Trusted Publishing Domain:

Import-RMSTrustedPublishingDomain -RMSOnline -name "RMS Online"

This will configure the required settings to enable IRM in your environment, as well as add two default IRM templates: Credential -Confidential, and Credential – Confidential View Only.

If you check your IRM configuration again after performing these steps, you’ll see the configuration changes that were made:


The final configuration step in this phase is to enable Internal Licensing by running the following command:

Set-IRMConfiguration -InternalLicensingEnabled $true

You can then test your IRM Configuration against a user in your environment to confirm that everything is set up properly. Note that at this point, no rules have been defined for encrypting email, but they are now able to be defined.

Test-IRMConfiguration -Sender jdahl@masterandcmdr.com


Once you’ve completed these steps, you’re ready to define encryption rules in Exchange Online.

Microsoft plants the Cloud in Canadian Soil

Microsoft announced today that they are planning on delivering Office 365, Azure and Dynamics cloud services from two brand new datacenters on Canadian soil – planted in Toronto and Quebec City. This is such awesome news, as it finally answers the roadblock that many Canadian companies have around their data living in US datacenters!

 
Whether this roadblock is justified or not, Canadian datacenters will open up many more opportunities for Canadian companies to move to the cloud and still keep their information safely in Canada.

 
These data centers are scheduled to go online in 2016 – I, for one, cannot wait!
Head over to http://reimagine.microsoft.ca/en-ca/ for the full press release and more details.

Creating a new user through copying (Office 365)

This is the third of three posts detailing how to create new users in a Hybrid environment. In this case, it was Exchange 2010 on premise, Hybrid to Exchange Online, with ADFS / DirSync, and SSO. There was some confusion with the Help Desk staff on how to manage their environment going forward, so I created this documentation for them. This procedure has worked well going forward, so I thought I’d post it in case anyone else found it useful.

In case you’ve missed them, here’s part 1, and part 2.

Creating a new user (copying an existing user)

It’s fairly common practice when creating a new user in AD to simply make a copy of someone who has similar permissions, or a similar role – it’s easier to get all their groups and permissions added, and less chance of missing something. If you want to be able to copy an existing user when you’re connected to Office 365, you can still do it – you just need to use a little bit of PowerShell after the fact to enable the remote mailbox.

In AD, copy the user account whose permissions you want to match:



Fill in your details as normal, and click Next:


Password, and then Next again:


And click Finish, and you’re done:


The next step is to enable their remote mailbox, so that they get properly provisioned for Office 365. Open the Exchange Shell and run the following command:

Enable-RemoteMailbox newjeremy -RemoteRoutingAddress newjeremy@domain.mail.onmicrosoft.com

Make sure to change the identity and the remote routing address to match the username of the user you’re creating.

If you get this error when you run the command in PowerShell:


It’s because the user that you copied from is still on premise, so it’s expecting the Exchange GUID to be in the attributes – fire up the old Attribute Editor in ADUC:


We need to remove the attribute for the msExchangeHomeServer, since we want that to be set to the cloud, not on premise:


The trick of course, is that you can’t delete it – otherwise you’ll get an error when you try to save your changes. Simply change this:


To this:


And then try running the command again – if that was the only problem, it should work properly this time.


Go ahead and force a sync if required, or wait for a few hours for the account to show up online:

You can manually push a sync of the directory by going to the DirSync server, and performing the following steps:

  1. Open PowerShell (Run as Administrator)
  2. CD to “C:\Program Files\Windows Azure Active Directory Sync”
  3. Run .\DirSyncConfigShell.psc1

  1. Type in Start-OnlineCoexistenceSync and hit Enter.

Go back to Office 365, and the user should show up now: – click on the new user to activate their licenses and a mailbox:


As I mentioned before, the only license required to assign a mailbox to a user is an Exchange Online Plan – Office 365 still maintains the granularity that allows you to give users only what they need / is assigned to them. Of course, if you need your users to have all the Office 365 options, just click the plan name at the top, which will check all the boxes underneath.

Next, click on settings, and set their location, then click Save.

It’ll take a few minutes for their mailbox to provision in the cloud – once it’s fully provisioned, you can go ahead and connect their account to Outlook.