GD Bloggers

This is the blog site for Microsoft Global Delivery Communities focused in sharing the technical knowledge about devices, apps and cloud.
Follow Us On Twitter! Subscribe To Our Blog! Contact Us

NEVER, AGAIN NEVER use a FQDN for the SharePoint 2010 SQL server name

NEVER, AGAIN NEVER use a FQDN for the SharePoint 2010 SQL server name

  • Comments 1
  • Likes

I really cannot stress enough on this. Really do not do this; you will save yourself TONS of problems.

You see I built a VM as a development VM for a project and when I was configuring SharePoint I said let me put the FQDN for the SQL server which was on the same VM. That was a single box with everything DC, DNS, SQL, SP, and VS. It went at first fairly well for normal SharePoint development. But when I dived in the heavy stuff and specially the shared applications everything went messy.

I was trying to configure the user profile application. It went good first and I was able to get the user profile service to start and then the application worked. BUT when I tried the user profile synchronization service everything went wrong. The service reported that it is starting and then after maybe 15 minutes it returns to the stopped state. I went through lots of articles about user permissions, SQL instance settings,… I tried to do everything I can from rebuilding the UPA from scratch to rebuilding the entire VM again and it did not work.

Finally as I was about to give up one of my colleges (THANK you Zsolt) asked me a very strange question (for me it is strange as it should have no effect on my problem) Did you configure the SQL of the SP using FQDN? I answered Of course!

He told me that he have seen this issue before with this type of configuration. So I un-configured SP; uninstalled it; removed all databases; then done everything again while using just the machine name and WOW it really WORKED!!!!!!!!!!!!!!!!!!!!!!!

I ended up wasting perfect 6 days of my life on this issue for no reason what so ever L One more remark; I was told also that the same issue would happen if I had used an IP address instead of the FQDN.

Conclusion: NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER use the FQDN specially if you are installing everything on the same box (I was also told that this would not happen if I was installing on multiple boxes but I never verified that)

EDIT

Just a note, if you already configured your servers using FQDN you can still solve the problem by removing all servers from the farm and adding them again one by one using the SQL server name (If you can afford that). I have not try it for multiple servers but for a single server install it worked and fixed the issue.

Comments
  • I have experienced the same problem myself. UPS sync never started. Double-checked every permission. I had to reinstall SharePoint and not using the FQDN for the SQL Server. Took several days to solve. I won't do this mistake again.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment