Tuesday, February 21, 2017

How to Set up Rooms Properly in Office 365


You'd think that setting rooms up in Office 365 would be a simple matter of going to the Office 365 Admin console, expanding Resources, clicking on Rooms and Equipment and then using the Add Button


This works but it doesn't do everything. If you want your rooms to appear in the Room List (and to show available times), you'll have to use PowerShell to put them there.


Finding Answers

So... I spent a while trying to find the answers without a whole lot of luck. I think that coming from the Notes/Domino world and not being familiar with the outlook terminology hindered me a bit in this regard. 

In any case, big thanks to IT for Dummies btw whose page called "Create Room List Office 365" made very little sense to me but helped me to explain to Microsoft Support what it was that I was looking for. 

BTW: Microsoft support can be reached via the Support and then Service Requests options in the Admin Center. I've found their support to be excellent. 

How to Set up Your Room
Having done the initial room creation steps (see the top of this post) you need to do the following to get it fully registered;

  1. Start Microsoft PowerShell (with local admin access)
    Note, this is normal PowerShell, not Azure PowerShell
  2. At the PowerShell prompt type:

    Set-ExecutionPolicy RemoteSigned

    This essentially grants you higher privileges for the current session.
    (you'll probably be prompted for a Yes answer).

    The returned wording will be something like this;

    Execution Policy Change
    The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic at http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?

    [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"):

  3. Next type;

    $UserCredential = Get-Credential

    This logs you in - it will prompt for your Office 365 admin user name & password.

    The returned wording should be something like this;

    cmdlet Get-Credential at command pipeline position 1
    Supply values for the following parameters:
    Credential

  4. The next command sets up an office 365 session connecting to exchange.

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

    The next command apparently imports the commands for exchange into the current session. (ie: makes them available for use).

    The returned wording should be something like this;

    WARNING: The names of some imported commands from the module 'tmp_aipbhxxl.kcz' include unapproved verbs that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb.

    ModuleType Version    Name                                ExportedCommands
    ---------- -------    ----                                ----------------
    Script     1.0        tmp_aipbhxxl.kcz                    {Add-AvailabilityAddressSpace, Add-DistributionGroupMember...


    I have no idea what this means or why it's relevant to me... best to just ignore it.
  5. Our next PowerShell command actually manipulates the rooms, so this is the first command that you'll need to have custom bits on.

    There are two parts to this;

    Part A: The Room List - This can be anything at all, it's just a way of describing the rooms collectively. If you've only got one set of rooms, you might as well call it "Local Rooms" but if you have separate rooms, for example, "Executive Rooms" and "Core Meeting Rooms" or "Building 1 Rooms" versus "Building 2 Rooms" then you'll want to describe this bit more carefully.

    Part B: The Room Names - In our case, we had four rooms, the Board Room, Large Meeting Room, Small Meeting Room and Projects Meeting Room.  You'll need to gather all of the rooms for a given list together and execute the command once -- because you can't add rooms to the list later (more on that afterwards).

    You'll need to use the short names for the rooms (the first part of their email addresses) as the room names in this command aren't supposed to have spaces in them.

    Here's the command you should submit;

    New-DistributionGroup -RoomList -Name 'Local Rooms' -Members BoardRoom, LargeMeetingRoom, SmallMeetingRoom, ProjectsMeetingRoom

    The response is downright weird... and a bit ... advertising..

    New! Office 365 Groups are the next generation of distribution lists.
    Groups give teams shared tools for collaborating using email, files, a calendar, and more.
    You can start right away using the New-UnifiedGroup cmdlet.

    Name        DisplayName GroupType PrimarySmtpAddress
    ----        ----------- --------- ------------------
    Local Rooms Local Rooms Universal LocalRooms@xxxxxxxxx.onmicrosoft.com

  6. To verify that the rooms were adjusted type the following;

    get-recipient -identity localrooms

    It should return and indication that there's now a distibution group called Local Rooms.

    Name        RecipientType
    ----        -------------
    Local Rooms MailUniversalDistributionGroup

  7. Of course, you could just close Outlook and reopen it and create a Meeting to check. 

One last note... the Microsoft team told me that if I needed to add a room to the group, I would be best off deleting the Local Rooms group and running the creation/linking command again. 

Thanks again to the Microsoft support team. I don't know how I would have figured this out without their help. 

Sunday, February 19, 2017

Solving Some Azure Active Directory User Synchronisation Issues on Office 365

We started moving over to Office 365 quite a while before we decided to ditch Notes mail and move to Outlook. It was also my plan to get rid of our internal active directory server and rely solely on the cloud for authentication. 

As it turned out, management wanted to keep the AD server a little longer, so we've had to synchronise our onsite accounts with the Office 365 ones. The synchronisation processes immediately created duplicates (and sometimes triplicates) of users. 

The journey to resolve this issue was time consuming and data destructive, so I thought I'd let everyone know how to fast-track it.


What Causes the Problems

Microsoft's Office 365 users have unique ID's much like the objects in the Active Directory. When you create a user from scratch on Office 365, you create them with a unique ID. While there are tools that will let you change these unique IDs, we've found that they generally do more damage than good.

Deleted people are another part of the problem, If you delete someone and then let the system recreate them, it will happily recreate them but won't set their ID properly. This is because their ID isn't unique. It's still in the person "recycle bin". To truly delete someone, you need to use the PowerShell command line.

Backing Up First

Before I jump into the whole process, you need to make sure that you back up things. Deleting users is fairly data-destructive.


  1. If your users have anything on OneDrive, take a local copy of it all.
  2. If your users have data in Sharepoint or Yammer, backup what you can.
  3. Transfer Ownership of Groups in Yammer and Sharepoint very carefully - don't delete all the Admins at once because you may have trouble getting them back. 
  4. Backup any Outlook mail they may have to a PST file (they'll lose mail)
  5. Make a note of any licences they have. 
  6. Do whatever you need to about OneNote 

Getting into Microsoft Azure Active Directory

You have to have Microsoft Azure Active Directory Module for Windows PowerShell installed.
Note that this is different from PowerShell and it's different from the AD Module for Powershell. It's hard to find the right version of the right software - at the time of writing, you need version 2.

In case you're interested in other Azure AD commands, here's a handy reference.

The first command is to connect to the Azure AD;

Connect-MsolService

You'll be prompted to login (so hopefully you'll use a user who has Global Administrator access).


Next, you will want look at the records of users...

get-msoluser -UserPrincipalName jsmith@mycompany.com |fl

This command line will show you jsmith's record.  Things to look for in the text include;

ProxyAddresses        : {SMTP:jsmith@mycompany.com
ImmutableId           : Pjo+HQRGtXm9GsUXzYYRqQ==
DisplayName           : John Smith
SignInName            : jsmith@mycompany.com
UserPrincipalName     : jsmith@mycompany.com

We found that our Proxy Addresses didn't start with SMTP: and that our Immutable IDs often had people's names (eg: jsmith) in them, instead of the ID.

The SMTP thing can be fixed but if your immutable ID is wrong, you really need to look at destroying the profile record and recreating. We've found that all of the records we destroyed have recreated properly but that the ones where we've just changed the proxy still have some glitches. I'd personally recommend removing everything.

Deleting People from the AD

You'll find that you simply can't delete a person in the Office 365 AD, particularly if they're synched from a local server. The GUI just won't work. You need to delete via command line.

Make sure that you check which licences they have been assigned because you'll want to reallocate them back.

remove-msoluser -UserPrincipalName jsmith@mycompany.com

Deleting a user is not enough though. You have to knock them out of the trash, otherwise they'll reside there for 60 days and prevent recreation via the AD synch process.

Even if your user wasn't having issues with their immutableID, they could still be having problems with Synch and email because of similarly named deleted people.

Before you delete, make sure that you've backed everything up. Emptying the trash is permanent and there's no recovery.The empty trash command is more or less the same as the delete command but with an extra switch (-RemoveFromRecycleBin)

remove-msoluser -UserPrincipalName jsmith@mycompany.com -RemoveFromRecycleBin

Wait for AD Synchronisation

In our case, AD synchronisation is set to 30 minutes. You can check via the front page of the admin centre. You might have to click More and then Refresh to get things to display properly because Office 365 doesn't always automatically refresh person lists or time displayed on the screen.

Once the next synchronisation has run, you should see the record appearing.

Some Fixes on the Local AD Record

We also had to do a couple of fixes on our local AD record, particularly making sure that the ProxyAddresses start with SMTP.

To do this;

  1. Go to your local Active Directory Server.
  2. Open users and Groups and get to our users.
  3. Edit the User Record.
  4. Go to the Attribute Editor Tab
  5. Find ProxyAddresses and double-click on it.
  6. If the address is something like: jsmith@mycompany.com then click on it and click REMOVE
  7. Then type  SMTP:jsmith@mycompany.com and click Add.
  8. If you need two, you might also want to type smtp:jsmith@mycompany.onmicrosoft.com
  9. (note the first/main SMTP is capitalised and the second is lowercase ... yes, seriously).


Reassigning Licensing and Finishing Up

Back in the Office 365 GUI, you'll want to go back into the person's user record when they appear.
Reselect their country
Re-add their licences.

You'll probably want to re-check their outlook settings but you can't because you have to wait for it to be finished being setup.

Repeat the process for all other users. Note that there are options for wildcard deletions and mass trash emptying. I haven't covered them here because the command line was fast enough for me and I don't really want to be responsible for someone trashing their entire Azure AD.

A big thanks to the amazing Microsoft support team in Shanghai who figured out some of the more technical parts of this process and walked me through them. 

Monday, February 06, 2017

OneDrive to Rule them all ... or perhaps not.

Microsoft OneDrive is great! It's easy to use too and has some really great integration into Office 2016 - which means that when you go to save or open files, instead of displaying a file dialog, it renders the folder names right into the panel. Sadly the sharepoint integration in Office 2016 is still dialog-based. 

On the surface, it looks like a great files storage solution but as it turns out, just like Tolkien's OneRing, beneath that shiny surface, OneDrive is mostly evil. 

At work, we're still using an old file server which allows people in the company to save files into public, personal or restricted access areas.

It's a great browsable structure with the main drawbacks being that it's on a local file server (which means ageing infrastructure and semi-manual backup procedures) and security because it needs a VPN to get to our internal systems. Many of our users still find a VPN too complex to set up and it's hard to get a VPN that runs on all flavours of devices (various versions of iOs, Windows, Android and Linux) without compromising security.

The file server also has shadowing, which is a great feature -- and sadly, something that Windows finally "copied" from the old Novell Netwoare 3.12  (1991) - after more than a decade of broken promises. Shadowing is awesome and adds a layer of recovery to your systems, especially when it comes to attacks like Cryptolocker.

Having seen OneDrive personal in action, I was keen to get OneDrive for Business. It seemed obvious to me that this was the solution - A cloud version of the file server that was tighty integrated into Office 365.

As it turns out, it's not. 

OneDrive For Business is Still Personal!

OneDrive for Business is basically OneDrive personal with some more space.

  • Neither sharing or rights management works properly on it.
  • All files on all versions of OneDrive are owned by a single owner, rather than the business.
  • It's not easy to copy files to OneDrive from a server, so I tried copying them locally, letting them synch and then removing the local copies. It doesn't do anything immediately but after a little while, it replicates the removal of those files over to OneDrive (yes, it deletes your files).

    I think there's a way to stop synching before doing this but I didn't bother giving it a try because it was pretty obvious that for all its beauty, OneDrive doesn't work.  


I talked to Microsoft about the problem and they made it very clear.

"Do not use OneDrive if the intention is to Share Files"

There's a very good blog post that explains this -- and it includes a flowchart too!
https://en.share-gate.com/blog/you-should-not-be-migrating-to-onedrive-for-business

Apparently Sharepoint - team sites is the tool for this.

SharePoint is not the Answer 

I looked at SharePoint and ran some tests to see how easily I could migrate our many years and many gigabytes of files shares.

Not easily at all.


  • We had to change the default settings on Sharepoint 365 just to allow us to upload more files. The default restrictions are all wrong (and the settings changes are buried quite deeply).
  • The file structure isn't properly browsable and it simply doesn't give us what we wanted.
  • The integration with Office 2016 is terrible compared to OneDrive.
  • There's a copy feature in OneDrive that allows you to copy OneDrive data to a team site. It's a copy though, so you still have to delete the files off OneDrive later.  It worked very well for small numbers of small files but whenever I tried to do anything useful with it, it failed. 


Looking for Answers Elsewhere

With reluctance, we began looking elsewhere and stumbled upon Citrix Sharefile.

We've had a demonstration and thus far, this looks like it's the right answer. I'll post my findings once I've had a proper chance to play.

In the meantime, there's some great videos for Sharefile on YouTube and it looks like OneDrive is reduced to being an option for HOME drives only. For data that the company doesn't mind losing.

I'm very concerned that Microsoft doesn't seem to have an answer to the file sharing problem. Particularly when people will be expecting to move from On-Prem Microsoft file servers to their Office 365 cloud.