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 *.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.
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 184.108.40.206). The VIP address is the IP address I need to direct my external DNS to.
“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://220.127.116.11). This in my case took me to the default IIS site however this will depend on your configuration.
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.
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.
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.
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.
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.
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.
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.”
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!
Kill the “lync.exe” process (use Task Manager to end the process)
Create a new local user account on the computer (lusrmgr.msc)
Add this account to the Administrators security group
Navigate to the Program Files directory for Lync 2013 (C:\Program Files\Microsoft Office 15\root\office15\)
Whilst holding the SHIFT key down, right click on the “lync.exe” application and select “Run as different user”
Enter the username and password of the account that was just created
Lync 2013 should open and launch the “New user configuration” window
Sign in to Lync 2013 with your Office 365 username and password
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!