Using PowerShell with Windows Azure

If you’re working with Windows Azure and want to use PowerShell to perform management tasks you will first need to install and configure Windows Azure PowerShell as per this article “How to install and configure Windows Azure PowerShell“.

  1. Download and install the Microsoft Web Platform Installer
  2. Launch the Microsoft Web Platform Installer
  3. Select the Windows Azure PowerShell and then click install
  4. Launch PowerShell as an Administrator
  5. Type get-help *Azure* to see all the Windows Azure cmdlets – you will be asked to update help
  6. Download your Windows Azure subscription publish settings file by typing Get-AzurePublishSettingsFile or by browsing to the download publish profile page
  7. Save the publish settings file to a directory – in my case I store this alongside my Windows Azure scripts directory that I have synchronised with Dropbox
  8. Import the publish settings file by typing Import-AzurePublishSettingsFile <PathToPublishSettingsFiles>
  9. Check to see that you can are connected to your Windows Azure subscription by entering Get-AzureSubscription which should return information about your subscription.

Here are a couple of useful links to get you started – Windows Azure Management Cmdlets and Windows Azure Script Centre

That’s it – you should now be able to manage Windows Azure using PowerShell.

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 where it advised you should use CNAME records and point these to your * 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 ( 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 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 ( 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 ( 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 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 synchronisation. You can do this by reviewing the application event log for entries that indicate when 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 the value of the “Synctimeinterval” key – the notation of this is Hours:Minutes:Seconds.


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

You can verify that 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 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.

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

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


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 some time 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 users are part of a 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 set up correctly – even broke out fiddler and checked 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 was aware of the bug and did not expect it to be resolved until September time. Others were saying that it worked with users whose machines were not joined to an Active Directory domain. This leads me to think about try using a local account and there it is folks – my solution!

This is less of a solution but more of a workaround 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!