Pointing external DNS at a Windows Azure hosted Virtual Machine

Update: while the VIP address is guaranteed for the lifetime of the deployment – a customer recently lost their VIP address which resulted in their custom domain name become unresolvable. Whilst this was acceptable as we were still in a phase of testing it did cause me some concern. Why had the VIP address changed without our knowledge – we had not made any configuration changes to causes this.I did some further research and found an article (Using custom domain names with Windows Azure Cloud Service) in the Documentation section on the Windows Azure website were it advised you should use CNAME records and point these to your *.cloudapp.net domain name. I asked the customer to do this and we have been able to use the system since.

This post describes how I configured one of my Windows Azure hosted Virtual Machines with my domain name registrars DNS  – this meant that I could make SharePoint 2013 available using my domain name.

On the virtual machine instances page in the Windows Azure Management Portal (https://manage.windowsazure.com) browse to the virtual machine you want to configure  with your external DNS.

Windows Azure Virtual Machine Dashboard
Windows Azure Virtual Machine Dashboard

On the right in the “Quick Glance” section you will see that a “Public Virtual IP (VIP) Address” is listed (this is shown in the image below but for security purposes I have changed my VIP to 111.111.111.111). The VIP address is the IP address I need to direct my external DNS to.

Virtual Machine Quick Glance information
Virtual Machine Quick Glance information

This VIP address is guaranteed to remain for the deployment of the cloud service – therefore if the deployment is removed the VIP address will no longer be available. Corey Sanders has written a great article on the Windows Azure MSDN blog (http://blogs.msdn.com/b/windowsazure/archive/2011/07/06/windows-azure-deployments-and-the-virtual-ip-address.aspx) where he confirms that the VIP is guaranteed for the lifetime of deployment and provides a great alternative if the virtual machine deployment has to be removed.

 “If that is not possible (e.g. you must delete/deploy), then a little planning beforehand can still help here: just create a new hosted service, update CNAME and A record to new hosted service (but keep old deployment there). Wait 24 hours and it should be safe to delete the older deployment.”

I also decided to add a shorter TTL to my A record just in case the VIP address does ever change for whatever reason and I need to propagate a change quickly. I’m not sure if this is advisable or not and am seeking confirmation on this.

A quick test you can do before making any changes to your DNS is to browse directly to your VIP address (http://111.111.111.111). This in my case took me to the default IIS site however this will depend on your configuration.

IIS 8 default website landing page
IIS 8 default website landing page

After I confirmed that the VIP address was accessible I then proceeded to make changes to my external DNS through my domain registrars control panel – in this example I wanted to point a host record (or an A record) to my virtual machine.

Change the default sync interval – Windows Azure Active Directory Sync

The default interval for Windows Azure Active Directory Sync (DirSync) synchronisations is 3 hours. If for instance your Active Directory has lots of changes you you’ll probably want to consider shortening the sync interval.

The schedule can be modified by changing the “Microsoft.Online.DirSync.Scheduler.exe.Config” configuration file. Before proceeding to make any changes to the sync interval you should evaluate how long it takes to complete a synchronisation. You can do this by reviewing the application event log for entires that indicate when a sync has started and completed.

To modify the configuration file open “C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.Config” in Notepad. You will then need to modify value of the “Synctimeinterval” key – the notation of this is Hours:Minutes:Seconds.

Microsoft.Online.DirSync.Scheduler.exe.Config
Microsoft.Online.DirSync.Scheduler.exe.Config

Save the configuration file and restart the “Windows Azure Active Directory Sync Service” Windows Service (via PowerShell Restart-Service MSOnlineSyncScheduler) to apply this change.

Restart-Service MSOnlineSyncScheduler
Restart-Service MSOnlineSyncScheduler

Force a full syncronisation – Windows Azure Active Directory Sync

When configuring Windows Azure Active Directory Sync (or DirSync as it was previously known) it’s useful to be able to run various synchronisation tests. The default synchronisation schedule is 3 hours so unless you want to wait you will need to force a full synchronisation using PowerShell.

Start-OnlineCoexistenceSync cmdlet
Start-OnlineCoexistenceSync cmdlet

To do this you need to load the Windows Azure Active Directory Sync PowerShell module and run a cmdlet. Start by navigating to “C:\Program Files\Windows Azure Active Directory Sync” in PowerShell and then run “.\DirSyncConfigShell.psc1” from this directory. This will launch a new PowerShell console with the Windows Azure Active Directory Sync PowerShell module loaded (Add-PSSnapin Coexistence-Configuration). Then to force a full synchronisation you need to run the Start-OnlineCoexistenceSync cmdlet.

[code lang=”PowerShell”]
Start-OnlineCoexistenceSync -fullsync
[/code]

You can verify that a synchronisation has occurred by reviewing the application event log on the server running DirSync – there should be several items in the log such as “Directory Synchronization, Event ID – 114, Export cycle completed”. There is also a status of the Active Directory Synchronisation on the “Users and Groups” page in the Office 365 admin portal. There are also two other ways to see the status of synchronisation jobs which I will go into in more detail in a later post but these include using the Forefront Identity Manager (FIM) client and Fiddler a web debugging proxy.

Office 365 Active Directory Sync status
Office 365 Active Directory Sync status

You can create a shortcut to “C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1” on the desktop for ease of administration. I however take this one step further and create a shortcut to perform a synchronisation as well. Create a shortcut with the following target below.

[code]%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -PSConsoleFile "%PROGRAMFILES%\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1" -Command "& Start-OnlineCoexistenceSync -fullsync[/code]

Workaround to “the server is temporarily unavailable” when signing into Lync 2013

Since our Office 365 tenant was upgraded we’ve been experiencing difficulties with our users signing into Lync 2013. When these users tried to sign in, the Lync 2013 client returned an error saying it could not communicate with the server. The users received the following error.

“The server is temporarily unavailable.”

The server is temporarily unavailable
The server is temporarily unavailable

Background

Firstly our IT guy raised this issue with Office 365  through a support ticket some months ago when we started experiencing this issue. There was some back and forth communication however no solution was ever found. As far as I know the issue is still open.

A few months passed and I was getting more and more frustrated that I wasn’t able to communicate with my team using Lync so I decided to spend sometime and see if I could find a solution myself.

Here is some other background information about our configuration…

  • Domain joined machines using Office 2010 were ok
  • Mobile clients were fine
  • All user are part of an Windows 2008 R2 Active Directory domain that is not connected to Office 365 through ADFS or DirSync
  • User accounts experiencing the issue have spaces in their account name (Joe Bloggs)
  • The Office 365 DNS records are setup correctly – even broke out fiddler and checked the my Lync client was reaching it’s end-points correctly which they were
  • Our internal domain is using an unresolvable .local address

After reading countless forum posts I noticed many others were reporting similar issues and the issue seemed quite widespread.

So after some research I read that Microsoft were aware of the bug and did not expect it to be resolved until September time. Others were saying that it worked with users who’s machines where not joined to an Active Directory domain. This lead me to think about try using a local account and there it is folks – my solution!

This is a less of a solution but more of a work around whilst Microsoft fix this issue once and for all!

  1. Kill the “lync.exe” process (use Task Manager to end the process)
  2. Create a new local user account on the computer (lusrmgr.msc)
  3. Add this account to the Administrators security group
  4. Navigate to the Program Files directory for Lync 2013 (C:\Program Files\Microsoft Office 15\root\office15\)
  5. Whilst holding the SHIFT key down, right click on the “lync.exe” application and select “Run as different user”
  6. Enter the username and password of the account that was just created
  7. Lync 2013 should open and launch the “New user configuration” window
  8. Sign in to Lync 2013 with your Office 365 username and password
  9. The Lync 2013 client should now happily work

I should highlight that some features such as creating a Lync meeting through Outlook might not work due to the processes running as different user accounts. Try it out for yourself and see.

Fingers crossed Microsoft fix this issue pretty soon!

Configure delegated administration on a Office 365 tenant

Update: July 2015 Some readers have kindly brought to my attention that after reading this post, they were concerned as to data security. Having read this post back, some two years on, I can see how some misunderstanding can be made from this post, so I’ve updated the article to reflect this. Finally, the disclaimer on this site has always suggested you validate information with secondary sources. Microsoft also publish information around how the protect and secure data in Office 365 on their Office 365 Trust Center site – please use this for any concerns around data protection. Additional information: Partner admin center

At the time of writing this post I was working for a “Microsoft Cloud Accelerate” partner. As a result of this, certain user accounts within our own Office 365 tenant were able to provide support to the partners customers, that explicitly agree to the partner providing ‘delegated administration’ to their Office 365 tenant.

Delegated administration allows selected users to perform ‘delegated administration’ functions to Office 365 tenants (those that have allowed this) using their own credentials. This could be creating support tickets, managing users accounts and resetting passwords to configuring their services – it also possible to support customers with SharePoint Online.

All of this of course, from setting up ‘delegated administration’ through to supporting customers through this function should be agreed and authorised with the customer. A key point to make clear with your customers is that by establishing the ‘delegated administration’ trust, the partner has access to provide ‘delegated administration’ to Office 365 services, subscriptions and SharePoint Online for example in their Office 365 tenant.

Create a delegated administration offer for your customers

To create a delegated administration offer for your customers you must do the following:

  1. Browse to the Partner Overview page (https://portal.microsoftonline.com/Partner/PartnerHome.aspx)
  2. Click on the link “Send delegated administration offers” link.
  3. Copy the information that appears in the window and send this offer on to your customer(s). The offer isn’t customer-specific so you can reuse this offer for multiple customers.
Delegated administration offer template
Delegated administration offer template

The customer must then click on the link they receive and proceed to authorise you the partner as a delegated administrator of their Office 365 tenant. You will the receive an email confirming they have configured delegated administration.

In order for users within the partner organisation to perform delegated administration they must be given administrative access to companies you support.

"Assign administrative access to companies you support" permission
“Assign administrative access to companies you support” permission

To do assign users with the permission they need you must complete the following:

  1. Navigate to the “Users and groups” page.
  2. Find the user you wish to give this permissions to and select “Edit”.
  3. From the “Settings” page scroll down to the “Assign administrative access to companies you support” and select “Yes”. This will then give the user access to the “Partner overview” page.
  4. Then choose the appropriate role, and then click “Save”.  The full administration role has the same privileges as the global admin role for the companies you support. The limited administration role has the same privileges as the password admin role for the companies you support.

Performing delegated administration

To do administer a customers Office 365 tenant you must use the “User and domain lookup tool” that is available on the “Partners” tab. Here you can enter your customers information it will bring back information about the tenant such as the subscription type and contact information. This page also displays three links to “Administer on behalf of”, “Create service requests” and “Show all administrators”. The “Administer on behalf of” link will then takes you to the “Office 365 admin center” where you can manage and administer their tenant.