SharePoint 2013 & Azure Installation / Configuration “Gotchas” & Troubleshooting

Category: SharePoint

sharepointAzureGuideAs a follow up to previous post on getting started with SharePoint 2013 on Azure, I thought it might help to list some of the small hurdles I had to overcome to get my environment fully functioning. If you happen to run into some issues getting things running, hopefully one of the items I have listed below will help you. Feel free to tweet me if you have anything to add to the list.

1. You have more than one Azure account

* 9/16/13 NEW– I found a site by Thorsten Hans on how to use a X509 certificate instead of messing with the .publishsettings file to switch between Azure accounts if you do not want to have to mess with the fix listed below:

I have a personal Azure account & one from my MSDN subscription. You may have one for work, one for personal, etc. Get-AzureSubscription may need to be used if your default subscription is set to another. Remember to import the .publishsettings file for the account you want to use at that time.

To get a .publishsettings file, open your WAPS (Windows Azure PowerShell) window and type get-azurepublishsettingsfile. It should prompt you to login but if it does not make sure you are logged into the correct account you want to use at that time. The following is from the Microsoft site:

  • Save the .publishSettings file locally after using get-azurepublishsettingsfileSecurity note: This file contains an encoded management certificate that will serve as your credentials to administer all aspects of your subscriptions and related services. Store this file in a secure location, or delete it after you follow these steps. If you are having issues downloading the .publishSettings file for some reason from PowerShell, just login to your Azure portal and paste this URL into the browser instead, it should prompt to download it manually:
  • Import the downloaded .publishSettings file by running the PowerShell command: Import-AzurePublishSettingsFile
  • Publish your application to Windows Azure by running the PowerShell command: Publish-AzureService -ServiceName <unique-name-for-your-service> (I am not sure if this cmdlet is deprecated now, I only see publish-azureserviceproject in my IDE now.)
  • Verify once again you have set the correct account by typing Get-AzureSubscription -ExtendedDetails to make sure you see the correct account.

More help with this:

NOTE:* I was tripped up on how to change my default account that Azure PowerShell uses, I had to change the DefaultDataSubscription.xml file (see below):


2. You can’t run your PowerShell script even though you have the correct directory and .ps1 file name!

I guess not all folders / directories are trusted my PowerShell by default. See by the image below that you have to type a .\ in front of the path to make it work.


3. Your VMs can’t connect,  you can’t join your VM to the AD domain in Azure or they won’t communicate with to each other

I hope to share more on this soon but you probably will need to see if your VMs were created in the same Cloud Service, Virtual Network or possibly an Availability Set. Depending on how you setup your SharePoint farm on Azure, you may have one Cloud Service or you might have a separate Cloud Service for each VM. Unfortunately moving them in and out of Cloud Services seems a bit of a mess. Here are a couple of links that might help also, the first from Jason Himmelstein explains that the order you start and stop them matters as well as having an Affinity Group. The other link explains cloud services a bit more:

Order is everything when setting up SharePoint on Azure IaaS – Jason Himmelstein

How to Connect to Cloud Service Correctly – Microsoft



4. You can’t delete *** (something or other) *** !

I know you aren’t the kind of person that just gets frustrated and starts deleting everything in your Azure account in random order to start over… but let’s just say you have a “friend” that did this and you need to help them 🙂  If you are receiving random errors about not being able to delete your .vhd, your OS image, start with this automatic deprovisioning script from Yung Chou:

If this does not work, check out these links:

5. A *** (something or other) *** already exists with that name, but you don’t see it in your Azure manager

Since I had to run my script a few times to get it to work, there were object such as my VM or a virtual network that were still being provisioned in the background and I could not see yet. However, when I tried to run my PS script again they would fail. The answer to this issue basically is “wait”, everything won’t necessarily show up in 2 minutes. You can delete everything and start from scratch until you get it right if you like (I did).

6. DNS issues / Cannot join a server to the AD domain

I saw a couple of people posting on the web that they could not join their SQL server to the AD domain even though AD was properly configured as a Domain Controller. I don’t understand exactly why but in the Advanced Settings of the SQL server you had to hard code the DNS IP of the DNS server you specified in your Virtual Network. Not everyone seemed to have this issue, I only did when I configured manually. The last time I used the free PS script I did not have this issue.

7. Services in SharePoint will not run, are failing, you are having connection & crawling issues with errors in the Windows Event logs  and/or ULS logs

(This already assumes you are 100% certain you have given the correct permissions/roles to your accounts such as SP_Farm, SP_Services, on the SQL server etc.)  I don’t know why yet, but this really smart fellow from Microsoft (@EricHarlan) helped me figure out that somehow the Windows firewall software was blocking the connection between my SharePoint and my SQL VM. I followed the instructions and created an inbound firewall rule on the SQL server to allow SharePoint to talk to it, but it still had errors. I tested this via pinging to see if it could connect but it only worked when I turned the Windows firewall off completely on both VMs. I have turned my VMs off for now to be safe. I still do not have an answer on why this is happening however.

NOTE: * This is a HUGE security risk so if you have a public facing website with the Azure VMs, do NOT do this and get some “professional help” 🙂

8. It worked the last time I was using it, before I shut down the VMs to save money

If you shut down your VMs (and if cost is a factor I understand why), you could have lost your IP addresses. I am mostly certain that it is the external IP is the one lost, not the internal IPs. I am not sure if you have to reconfigure your environment again or not. Keith Mayer has written a good article on understanding this:

*TIP: Some people are keeping the lowest cost VM available on all the time so they do not lose their external IPs, sort of low cost way to keep the external IP where DNS records and such are attached. – Thanks to Chris Johnson for this idea

 9. You can’t RDP, Login, access via HTTP or SSH to your VM

Did you reboot? No, seriously…restart your VM or turn it off, wait and then turn it back on. Here is a good link of items to check over in your Azure portal if you have connection, login or authentication issues by a fellow named Craig Landis:

Troubleshooting Endpoint Connectivity (RDP/SSH/HTTP, etc. failures)

Another issue is regarding properly configuring endpoints and the firewall, see these posts:

 10. The build number of the image you are using in your PowerShell script is no longer valid / what are the current build numbers of the images available?

In your Windows Azure PowerShell screen type:

Get-AzureVMImage | Export-Csv -Path C:\AzureImageFileNums.csv

and this will return a list of all the available images with their image build numbers in a spreadsheet to your C:\ drive. There is also a website by Tarun Arora that is updated daily list of TFS software build numbers.

11. Use lower case letters!

I didn’t know this when I ran the PowerShell script that configured everything, it bombed a couple times before I figured out you cannot use capital letters in your component naming.

12. The supplied password must be XXXX characters long and meet password complexity requirements.

Currently an Azure VM password is set at 8-123 characters long, but the reality of the internet is that all companies are going to require more stringent and complex password requirements as time progresses. Make sure if any of the PowerShell scripts you use have a place to set the password that it is a crazy complex password so your script will run.


Other Resources:

Windows Azure Support Forums

Top Support Issues in Azure – MSDN



(Visited 2,069 times, 1 visits today)

Please rate this blog post!