Category Archives: Office365

Adding branding to the Office 365 portal

Hi all,

Today we’re going to change the branding of the Office365 portal. Something that helps clients identify that they are logging into the correct portal and are entering their usernames correctly. The great thing about this is you can have your own support information directly on the office365 portal.

you should make notes of some prerequisites before you start:
Company branding is a feature that is available only if you are using the Premium or Basic edition of Azure Active Directory, or are an Office 365 user. To check if branding is available you can try the following link

If you’ve checked that you can use branding, and you have your Office 365/Azure Admin account available you first log in on the portal at https://portal.microsoftonline.com, If you’ve previously used Azure you can directly log into Azure using https://portal.azure.com

After logging in browse to the admin panel and click on the “Azure Active Directory” link in the sidebar. This will open the Azure Portal. In case you have never signed into the Azure portal you will be forced to fill in some minor information such as e-mail address and physical address.

When logged into the Azure Portal you can click on Azure Active directory in the sidebar. You will not be presented with the following screen, Click on the area i’ve marked as yellow;

Screenshot01
After clicking, a new sidebar appears and you can select the option to “Configure Company Branding Now”. You can upload your images directly and also change the login tips and support information. After uploading your images you can log out of the portal. When logging in again you will see the branding as soon as you’ve entered your e-mail address or when you log into the portal using the URL https://outlook.com/tenantname(e.g. outlook.com/constoso.onmicrosoft.com). If you want users to access the webmail or portal using their own domain-name my advise would be to create a forward from webmail.clientname.com to https://outlook.com/tenantname.

An example of the branding can be found below;

A screenshot of the branding applied

A screenshot of the branding applied


Happy branding! 🙂

Creating a Poor Man’s Express Route

Lately we’ve been running into issues with client’s connecting to Office 365 and having high latency with this connection. this results in issues such as “Outlook is not Responding” & “Getting data from server outlook.Office365.com”. Both of these issues disappear when running in Cached mode due to less data-traffic being required for normal operations such as opening e-mails and retrieving folder lists.

After researching we’ve found that this is mostly related to enormous detours that the ISP was taking to reach the Office 365 back-end. Mostly due to “cheaper” connections to the DUB(EU) or AMS(EU) data-centers of Microsoft. A good example of this can be seen with the Dutch ISP RoutIT, where you have 28 hops on average to the Office 365 back-end(of which 90% is still in their network), but only 5 hops to the Azure back-end strangely enough. After contacting Microsoft Support we’ve got the dreaded answer: Please invest into an Express-Route solution to circumvent these issues or have the provider resolve the connection problems.

We have multiple small sites with 5+ users that simply cannot afford this, and the clients can’t accept this latency. So we decided to ignore Microsoft’s advice and go on our own path of discovery 😉 After reading some of the service descriptions we’ve found that Microsoft assures better connections from Azure to Office 365 by using extensive QoS, and of course simply because the virtual machines are in the same network as the Office 365 services.

I’ve created the step-by-step below to research, test, and implement a solution.

Research

first we needed to discover if the client actually suffered from this issue:

  • Open outlook on a user with connection issues.
  • Right-click the tray icon, while holding CTRL and click on “Connection Status”
  • In online mode you’d want the AVG. Proc time to be lower than 25(Cached mode this can be anything from 25-300)
  • In online mode you’d want the AVG RTT Time to be lower than 200(Cached mode this can be anything from 0-1000)
  • If you have results higher than above, you are possibly having issues connecting to outlook.office365.com and a poor-man’s ExpressRoute might help you run your outlook in Online mode.

After these tests, we run a Traceroute to tripple-check if the route is the issue, or if the connection latency itself is the issue. You expect a traceroute to Outlook.office365.com to always be less than 20 hops, preferably in the 10-15 range, such as my results;

tracert outlook.office365.com

Tracing route to outlook-emeacenter.office365.com [132.245.229.114]
over a maximum of 30 hops:

  1     1 ms    <1 ms     1 ms  xxx.xxx.xxx.xxx
  2     9 ms    9 ms    10 ms  xxx.xxx.xxx.xxx
  3     7 ms     8 ms     7 ms  ae0-33.crt02-gsw.redhosting.nl [178.238.96.45]
  4     4 ms    4 ms    12 ms  ae0-31.crt01-nkf.redhosting.nl [178.238.96.37]
  5     4 ms    4 ms    13 ms  ams-ix-2.microsoft.com [80.249.209.21]
  6     6 ms    7 ms    14 ms  be-62-0.ibr01.amb.ntwk.msn.net [104.44.9.134]
  7     13 ms    12 ms    15 ms  be-7-0.ibr01.ams.ntwk.msn.net [104.44.5.33]
  8     14 ms    16 ms    16 ms  ae63-0.am3-96c-1a.ntwk.msn.net [104.44.5.1]
  9     6 ms     5 ms     5 ms  132.245.229.114

Trace complete.

If you have results as above, this solution might not be the one for you, Of course you can continue testing below but YMMV.

Create Virtual Machine Azure for performance tests & RRAS

Create a virtual machine in the Azure portal with the following specifications and configuration, If you have never created a virtual machine please use the  following guide on the Microsoft website. The interfaces changes every couple of months so its best to use the resources from Microsoft themselves.

Configuration:

  • at least 1 Core
  • at least 1.75GB of RAM
  • Static Internal IP for the server
  • Allow traffic: SSL to server(443)
  • Install the following roles: Remote Access, DHCP Server.
  • Setup DHCP and Remote Access.

After configuring the Azure side of the requirements make sure you configure SSTP VPN connections(Not required – For testing only.) and allow Router advertisement and IP forwarding. If you require a SSL Certificate you can use a free certificate from LetsEncrypt for this test.

After performing all configurations connect to the SSTP VPN from a client that experienced issues. Remember to set the “Use default gateway on remote network” to force all traffic over this tunnel for the sake of the test. Restart outlook and perform the testing steps once more. You should see a lower AVG. Proc Time and lower AVG. RTT Time. Have the user work on the SSTP connection for a day to see if they actually see a noticeable difference. If this is the case, its time for a more permanent solution.

Create IPSec tunnel

If the tests above have been performed, and you are ready for a permanent solution you can use Azure to create an ipsec tunnel, for that I advise the following guide.

After configuration of your ipsec tunnel, remember to tunnel all Office 365 traffic using the Microsoft IP address list found on this link. You can choose what traffic you route over the tunnel and what traffic you’d prefer using your local internet connection. When using the IPSEC tunnel remember that you must use your RRAS server as the gateway or else the routing will end on the side of the the Azure S2S VPN.

an ipsec VPN Tunnel and RRAS for NAT/Routing costs about 90% less than ExpressRoute, and might resolve most issue you have with sluggish outlooks, or slow responding Office 365 services.

Happy O365ing.

Managing Office 365/Azure tenants using powershell

One of the fantastic benefits of having Microsoft partner portal access is the ability to remote manage your clients/tenants. One of the downsides of this is that the partner portal is sometimes somewhat slow, or has a convoluted approach for remote management. A great way to resolve this is by using PowerShell to manage the tenants instead. This is just a quick post that could help you understand the commands involved;

First off – You’ll need to download and install the tooling required to connect with the Azure Powershell objects

  • Download the Microsoft Online Services Sign-In Assistant for IT Professionals: here
  • Download the Microsoft Azure Active Directory Powershell objects here

After downloading these and following all the required reboots you’ll be able to connect to Azure/O365 by issuing the following command in your new Azure Powershell Module;

connect-msolservice

After connecting to the MSOL service you now have access to the Microsoft online service modules. To manage your allowed partners we’ll first try to retrieve the tenant IDs that are available to us by executing the following command:

Get-MsolPartnerContract  | fl

Of course, this gives us way too much information – We only need to see the tenant id, to make sure we get this we execute the following:

Get-MsolPartnerContract -All
OR
Get-MsolPartnerContract -Domainname ClientDomain.ORG

Now with this tenant ID, We’re able to execute PowerShell commands based on the tenant instead of our own environment simply by adding -tenantID to the normal MSOL commands. e.g.

Get-MsolUser -TenantId tenantID | set-msoluser -StrongPasswordRequired $true

Happy PowerShelling!

Using Azure MFA on an onsite RDS 2012R2

Azure MFA is a fantastic product – Its easy to setup and maintain, and not very costly to purchase (for pricing, click here). The great thing about Azure MFA is that it becomes very easy to secure your local directory, but also your remote desktop connections or RDS your 2008/2012 farms. There is just one downside; Out of the box Remote Desktop(terminal services) security does not work on Server 2012R2. I’m not sure why Microsoft decided to not support 2012R2 RDP access. I actually have a ticket outstanding with the Azure MFA team.

Of course there a solution; instead of securing direct RDP access, you can decide to secure Remote Desktop Gateway and have your users connect to the Remote Desktop Gateway. This might sound like a large change but I always advise my clients to use RD gateway – mostly due to it being accessible from almost all locations due to running on port 443 and having SSL security is a nice added bonus.

To add MFA to RD gateway we need to perform the following prerequisites ;

  1. Deploy a standard RD-Gateway, with NPS. This can be done on a separate server, or on the RDS server if you have a small farm.
  2. Deploy Microsoft Azure MFA on a different server, Please note: MFA and NPS cannot run on the same server due to NPS and MFA Radius clients running on the same ports. For a good tutorial on how to install Azure MFA see the following link: link
  3. Open port 443 to your RD gateway server.
  4. Choose a shared secret and note it – We’ll use the example “ThisIsNotASecret”

After performing the first 3 steps, its time to set up RD Gateway, NPS and the Azure MFA Server

RD Gateway setup:

  • Open the RD Gateway console, and right-click the server name, choose the tab “RD CAP Store”
  • Turn off the “Request clients to send a statement of health” check box if you have clients that are not NAP capable.
  • Select “Central server running NPS” and remove the current server if there is any, Now enter the hostname of the MFA server and our selected shared secret “ThisIsNotASecret”.
  • Close the Console – we’re done on this side. 🙂

NPS Setup:

  • Open the NPS console and go to RADIUS Clients, Right click and select New
  • Enter a friendly name – e.g. AzureMFA and note this.
  • enter the IP of the MFA server & our selected shared secret “ThisIsNotASecret”
  • click OK and move to “Remote Radius servers” in the left hand menu.
  • Double click the default TS Gateway Server Group and click edit, select the Azure MFA server from this list and click on load balancing.
    • Change the priority to 1 and the weight to 50
    • change the number of seconds before a connection is dropped to 45 seconds.(could be less, but I select 45 seconds to keep uniformity among servers)
    • Change the number of seconds before server is unavailable to 45 seconds.(could be less, but I select 45 seconds to keep uniformity among server
    • Click OK and close this window. Move to Connection Request Policies
  • You should see the default connection policy here – disable or delete this, as we will create our own policies.
  • Right click the policies and select “New” Name this policy “Receive MFA Requests”. The settings for this policy are:
    • NAS Port type: Virtual(VPN)
    • Client Friendly Name: AzureMFA
    • Authentication Provider: Local Computer
    • Override Authentication: Disabled
  • Create another policy and name this “Send MFA requests”. The settings for this policy are:
    • NAS Port type: Virtual (VPN)
    • Accounting provider name: TS GATEWAY SERVERS GROUP
    • Authentication Provider name: TS GATEWAY SERVER GROUP
    • Authentication provider: Forwarding request
  • And that concludes the NPS setup. Almost there! 🙂

Azure MFA Setup:

The last steps are fairly straight forward:

  • Open the MFA administrator console and select the RADIUS option in the left hand menu.
  • Enable Radius and on the clients tab add the IP of the NPS server.
  • enter the shared secret “ThisIsNotASecret”.
  • Now select the tab “Targets” and enter the IP of the RDS Server.
  • Go to the left hand menu and select user. Enable a user for tests with SMS messages or the app.
  • Open the Windows Firewall for inbound Radius traffic
  • Test! 🙂 If you followed the manual to the letter you now secured your RD Gateway with MFA.

 

Happy MFA’ing! 🙂

Stop AADSync logs from clogging up your servers disk space

I’ve been rolling out a lot of large AADSync deployments recently – I love how AADSync gives a SSO experience to the SMB markets without having to deploy ADFS. But as always these deployments in SMB markets have some downsides; The default configuration for AADSync/Dirsync is that it logs everything using tracing and ForeFront MSSQL Logs.

On smaller deployments or deployments where diskspace is expensive you might want to limit the usage of these logs. Of course my advice as always is to only make these changes when your DirSync/AADSync environment is running well and not experiencing any issues whatsoever.

To prevent the SQL database from growing to absurd sizes:

param([int]$DaysToKeep=2)
$DirSync = Get-WmiObject -Class “MIIS_SERVER” -Namespace “root\MicrosoftIdentityIntegrationServer”
$DirSync.ClearRuns([DateTime]::Today.AddDays(-$DaysToKeep)) | Format-Table ReturnValue

Save this script as .\ClearDirSyncDB.ps1 and run it. Of course you can set this as a schedulded task to automate it.

To prevent the TRACING folder from filling with logs:

  • Stop FIMSynchronizationService service via services.msc.
  • Run Notepad or your favorite text editor as administrator
  • Open the MIISERVER.Config file at X:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\Bin\miiserver.exe.config (Where X is the drive you installed AADSYNC)
  • Paste the following after
  • </appSettings>

<system.diagnostics>
  <trace autoflush=”true”>
  <listeners>
  <add name=”DirectorySynchronizationTraceFile” type=”System.Diagnostics.TextWriterTraceListener” initializeData=”C:\Temp\DirectorySynchronizationTrace.log” traceOutputOptions=”DateTime” />
  </listeners>
  </trace>
  <sources>
  <source name=”passwordSync” switchName=”sourceSwitch” switchType=”System.Diagnostics.SourceSwitch”>
  <listeners>
  <add name=”console” type=”System.Diagnostics.ConsoleTraceListener”>
  <filter type=”System.Diagnostics.EventTypeFilter” initializeData=”Information” />
  </add>
  <add name=”sharedTextLogger” type=”System.Diagnostics.TextWriterTraceListener” initializeData=”PasswordSync.log”>
  <filter type=”System.Diagnostics.EventTypeFilter” initializeData=”Verbose” />
  </add>
  <remove name=”Default” />
  </listeners>
  </source>
  </sources>
  <switches>
  <add name=”sourceSwitch” value=”Verbose” />
  </switches></system.diagnostics>

  • Re-start FIMSynchronizationService service via services.msc.
  • Reactivate your syncronisation by running the configuration wizard and entering your domain details

And then you’re all done! dirsync should not longer eat up your precious diskspace 🙂

Creating hosted mailboxes while on premises mailboxes still exist.

One of the major drawbacks when using AADSync or Dirsync is that the remote mailboxes are not created when a local mailbox exists. This could prove difficult when migrating to Office 365 due to the mailboxes not existing simultaneously.

For instance we use third party migration tools that require the remote mailbox to exist. In a normal situation when assigning a office 365 exchange license to a user a mailbox is automatically created. When this user still has an on premises mailbox this will not happen due to the msExchMailboxGuid property that has been set in active directory. Removing this property also marks the mailbox for deletion in Exchange as it no longer is able to find the correct GUID for the user.

To resolve this we have 2 options, both require some work – It just depends on which you personally prefer

Option 1; Disable Dirsync or AADSync and create the mailboxes online.

 

The first option is quite simple and requires manual intervention, this option is best if the following statements are both true;

  1. you are not working in the Cloud environment yet and the users have never logged in.
  2. You are phasing out the local directory you are syncing from or are planning to remove Exchange locally on short notice.

If these are not true, I’d advise you to use option 2 which gives you more of a solution

First you remove licenses from all the users you have synced with Active Directory. Then disable Active Directory Sync. Your synchronized users will be converted into Cloud objects and you will be able to reassign licenses. When reassigning licenses an online mailbox will be created.

After 24 hours you can re-enable Active Directory Sync and the users Office 365 mailboxes will exist and ignore the msExchMailboxGuid

Option 2; Change the Dirsync or AADSync settings to prevent msExchMailboxGuid replication.

Another option is to prevent the synchronization of the msExchMailboxGuid – I often prefer this as I do not need to make any modifications to the already setup Cloud environment and it gives me more freedom when creating new users locally – I often incorporate auto provisioning script for mailboxes and other specialized items so I am still able to use these local scripts and not worry that the hosted mailbox will not be created.

As always, Please be careful when preforming these tasks. Do so at your own risk;

  • Launch X:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe (where X: is the drive you installed the sync tool.)
  • Click on “Management Agents”
  • Right click on “Active Directory Connector” and click on “Configure Attribute Flow”
  • Open the ObjectType:User property.
  • Find the to msExchMailboxGuid.
  • Click the Delete button to remove the mapping to the msExchMailboxGuid.
  • Click Ok to save the changes
  • Close the MIIClient.

We have now prevented new objects from syncing the msExchMailboxGuid property to the cloud – The problem that remains is that existing objects have already replicated this property to the Office 365 Azure Active Directory. To make sure that at the next import job we clear this property on the hosted side we will need to perform a few SQL tasks. First we use SQL Management studio to connect to the Servername\MSONLINE SQL instance. When connected we run the following query;

UPDATE mms_metaverse SET msExchMailboxGuid = NULL WHERE (msExchMailboxGuid IS NOT NULL)

When this query runs the status of the msExchangeMailboxGuid in the SQL database is set to NULL. Your local active directory object is not changed. Now you can force a full import using the miisclient or using the Dirsync powershell module.

After a successful sync we are able to reassign a license and the hosted mailbox will be created! That way the local and hosted mailbox coexist and you are able to replicate the data using third party tools.

Have fun migrating!