Getting Rid of GUIDs in DB names in an Exiting SharePoint Farm

DBAs hate the GUID appended to a database name. Everyone does! But that will happen if the farm and the Service Applications within are created with a wizard.



To make sure the database names are “clean”, farm admins can create the farm using psconfig.exe and create the Service Applications and Content Catabases with PowerShell. But what if a farm has been created and the databases already have GUID in their names? When you just take over a new farm, this may be the case, and you may be lucky enough to be assigned the task to change the names. ūüôā

Just do the steps below to get rid of the GUIDs:

For the Central Administration site content database, you need to move the site to a new Content Database. Follow the steps:

  1. Create a new databases with proper names and configuration.
  2. Move the sites with Move-SPSite PowerShell cmdlet to move the sites to the new databases.
  3. Verify the sites are working correctly after the move.
  4. Delete the old databases.

For the user Content Databases, you can rename the databases. Follow the steps:

  1. Dismount the database from SharePoint Web Applications with Dismount-SPContentDatabase PowerShell cmdlet.
  2. Rename the dismounted database in SQL Server with ALTER DATABASE T-SQL command or in the Object Explorer.
  3. Mount the renamed database to SharePoint Web Applications with Mount-SPContentDatabase PowerShell cmdlet.

For Service Application databases, you need to rename the databases with additional actions and it is specific to each service application. Check this TechNet article to find information for the service applications you are using.





Getting Prompted for Login Repeatedly

If you encounter repeated login prompt even when the credential entered is correct, there are some common solutions that can help. If the issue persists after all these solutions are in place, systematic troubleshooting will be needed.

Here are the common areas to check, on the clients and the servers.

Client Side Solutions

Add the team Web site to the list of trusted intranet sites

To do this, complete the following steps:

  1. On the Internet Explorer toolbar, click Tools, and then click Internet Options.
  2. In the Internet Options dialog box, click the Security tab, and then select Local intranet.
  3. Click Sites, and then click Advanced.
  4. Type the URL of the team Web site in the Add this Web site to the zone box, click Add, and then click OK.

Bypass proxy server for local addresses

To bypass your Internet proxy for local addresses in Microsoft Internet Explorer 5 or later, complete the following steps:

  1. On the Internet Explorer toolbar, clickTools, and then click Internet Options.
  2. In theInternet Options dialog box, click the Connections tab, and then click LAN Settings.
  3. UnderProxy server, select the Bypass proxy server for local addresses check box, and then click OK.

Make sure Integrated Windows Authentication is enabled.

Make sure Integrated Windows authentication is enabled in IE. (Tools >> Internet Options >> Advanced >> under security, enable integrated authentication)

Add the entry to the Credentials Manager

  1. Go to Start > Run and type in control keymgr.dll to open the Windows key manager.
    Alternatevily: navigate to Contorl Panel > User Accounts > Manager Windows Credentials
  2. Select Add a generic credential
  3. Add yourSharePoint site URL, login and password to the corresponding fields. If this entry already exists, edit it to have your login credentials.
  4. Reboot the computer.

If you are missing the Add button, you may want to modify Windows Registry to be able to save the password.

Note: for editing Windows Registry, administrator rights are required. Editing Windows Registry is not safe and users will perform it at their own risk.

  1. In Windows, go to Start > Run and enter regedit.
  2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\.
  3. Find the DisableDomainCreds A value of 1(enabled) will prevent you from saving new credentials.
    Change the value to 0 and reboot. Now you should have the Add button available. Note that 0 is the default value.
  4. Also check the LmCompatibilityLevel It should be set to 3, which is the default value. If you have another value, change it to 3. If it does not work with 3, then also try it with 2.
  5. Reboot the computer to apply changes.

If the client PCs are using Windows 7, some hotfixes may be needed:

The solutions below are specific to the ‚ÄúOpen with Explorer‚ÄĚ function. If you get prompted for login repeatedly when using “Open with Explorer” after trying the configurations above, you can try the solutions below.

Restart WebClient Service

  1. Click Start > Run
  2. Enter ‚Äėservices.msc‚Äô
  3. Find the WebCient service and select Restart

Check Internet Explorer Version

  • Windows 7: Internet Explorer 10 is not yet compatible with the You will need to revert to Internet Explorer 9.
  • Windows 8: Internet Explorer 10 is compatible, so you should not have an issue with this OS and browser version combination.

Server Side solutions

Specify Host Names on each SharePoint Web Front End. (Preferred method over disabling loopback check)

To do this, follow these steps for all the nodes on the client computer:

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:


  1. Right-click MSV1_0, point to New, and then click Multi-String Value.
  2. Type BackConnectionHostNames, and then press ENTER.
  3. Right-click BackConnectionHostNames, and then click Modify.
  4. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
  5. Quit Registry Editor, and then restart the IISAdmin service.

Client and Server Coordination

Make sure the NTLM Level is the same among Domain Controllers, SharePoint Servers and Clients

This can be pushed down from a Domain Controller using GPO (Group Policy Object).

  1. Use Group Policy Editor (GPE) to open the Group Policy Object (GPO) you want to modify. You can create a policy that applies to the OUs that contains the DCs, SharePoint Servers, and user clients.
  2. Navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options.
  3. Double-click the “Network security: LAN Manager authentication level” policy.

You can choose a level that is acceptable to your internal security policy, Just make sure you use the same level across DCs, SharePoint Servers and clients.

  1. Select “Define this policy setting” and from the drop-down menu select the desired level.
  2. Click OK.
  3. Close the GPO.
  4. To make the modification effective immediately, run gpupdate /force on all the servers and clients.

Why you need to host Intranet and Internet sites in separate farms?

If you have both Intranet sites and a public facing portal, it is usually recommended to host them separately in their own farms instead of sharing the same farm. Some may argue that these two types of site can actually be hosted on the same farm as long as they are separate web applications using different application pools and even separate instances of the same service applications. However, there still are factors to be considered:

  • Security ‚Äď The servers of Internet-facing website are close to external access. It is a recommended security practice to separate servers hosting intranet from those serving internet-facing websites. In this case, intranet farms servers could be placed in an internal network zone with no internet access.
  • Performance optimization ‚Äď Intranet sites and internet-facing web site have different usage patterns. Internet-sites are primarily read-intensive, while intranet sites have more user updates. The configuration for these two types of environment are different. For example, in database server hosting content databases, the transaction log files of write-intensive databases should be put in a faster drive than that of the data files. For read-intensive databases, the configuration is quite the other way.
  • Scalability ‚Äď The growth pattern and scaling requirement is usually different between intranet websites and internet websites. Take the sizing of one of my customers’ SharePoint farm as an example, the intranet portal has a content database of more than 50 GBs while the total size of each of the internet web applications is only around 1 GB. The user traffic growth pattern may be different as well. The intranet traffic is basically predictable based on the growth of internal users. That of the internet farm may change quite drastically if the website becomes more and more popular.
  • Maintainability ‚Äď The maintenance schedule is usually different between internal intranet and internet-facing sites. Farm maintenance task often involves, solution deployment, IIS reset and even server reboot. Separating sites into two farms will ensure maintenance on Intranet farm does not impact the internet-facing websites. What is more, internet-facing sites have the most stringent SLA. Correspondingly, a dedicated high availability and maintenance schedule should be implemented.

DNS Alias vs. SQL Server Alias

Setting alias for SQL Server provides the system extra capability in disaster recovery. In the case of an SQL server outage, the admin could bring online an identical instance (if any) and point the same alias to refer to the new instance. In this case, the clients may not even know the SQL server has been changed at the back end.

Therefore, it is recommended to have and alias in place. However, questions always come up as to the choice between a DNS alias and a SQL Serve alias. This article is for a comparison of the two option.

DNS Alias


  • It is more resilient (as mentioned at the beginning of the second video¬†here). Once it is setup, all the clients could take advantage of it. In the case of SQL server change, the update is only needed at DNS. All the servers using the same DNS will be able to pick it up.¬† Of course, DNS cache is not considered here.¬†For example, in a large SharePoint Farm, you don’t have to go into each server to update it.


  • This usually requires cooperation across teams, which may not be easy for many organizations. SQL Server, SharePoint and DNS are usually managed by different teams or personnel.
  • Single point of failure. If DNS is down, all the clients using the alias will be affected. What’s more, it is sometimes difficult to know who will be affected once the alias is modified because anyone could use it after it is setup.
  • You cannot specify ports. So the applications that connect to the SQL Server should either always remember the port or has to use the default ports.

SQL Server Alias


  • It is controlled at the application side, by the same team that manages the clients, such as the SharePoint team.
  • If the alias is set after the SharePoint farm is built, it is easier to configure a SQL alias. Just set it in the SQL Server Client Network Utility (Cliconfg.exe) and restart the server or restart the SharePoint services (Todd Klindt has a¬†post that includes this topic). For DNS alias, you will have to reconfigure the farm.
  • You can specify a different port other than the default one. In this case, to applications that connect to SQL Server, they only need to know the alias name.


  • It has to be updated at every client machine. If you have 10 SharePoint Servers in the farm, you will have to set and update the alias on each one of them.¬† If you don’t have a way to automate the update, there will be certain time of outage of the system.
  • The same name maybe used by different systems. For example, the alias “SQLDB” can be used for SharePoint to refer to SQL Server A, while on TFS, “SQLDB” is referring to InstanceA on SQL Server 2.¬† Once there is an integration between the two platforms, there will be potential confusion and problems.

This is my opinion¬†and you may have you own idea about this topic. If you¬†could share your thoughts,¬†I would really appreciate it.¬†ūüôā

Redirecting My Sites to Office 365

In this post, I would like to quickly share how to direct the My Site links in the On-prem SharePoint farm to Office 365 tenant.

This includes:

  • OneDrive for Business
  • “Sites” the user is following
  • Newsfeeds
  • “About Me”

It is probably very straightforward for admins to redirect the OneDrive for Business and the Sites page.  You simply need do the following:

  1. In SharePoint 2013 SP1 Central Administration site, navigate to Office 365 >> Configure OneDrive and Sites Links.
  2. On the Configure OneDrive and Sites links page, in the My Site URL box, type the My Site URL that you got from Office 365 portal administration.
  3. Specify an audience. Choose Everyone if you want all of your users to be redirected, or choose Use a specific audience, and type the audience name for the audience that contains your Office 365 users.
  4. If you also want to redirect the Sites page in users’ personal sites, select the Redirect the Sites page check box.
  5. Choose OK.

But what about “About Me”?

After the configurations above, you will still be directed to the on-premises My Site host. And if this is the first time, a My Site will be created for the currently logon user on the SharePoint Server farm. Actually, redirecting the link “About Me” is relatively ease as well. Just register a Trusted My Site Host location in the User Profile Service Application.

  1. On the Central Administration Web site, under Application Management, click Manage service applications.
  2. On the Manage Service Applications page, select the User Profile service application from the list of service applications.
  3. On the ribbon, click Manage.
  4. On the Manage Profile Service page, under My Site Settings, click Configure Trusted Host Locations.
  5. On the Trusted My Site Host Locations page, click New Link to add a trusted My Site host location.
  6. On the Add Trusted Host Location page, enter the URL of the trusted personal site location in the URL box.
  7. In the Description box, enter a description for the trusted personal site location.
  8. Optionally, in the Target Audiences box, either type the user names or group names in the corresponding box or click Browse to select audiences by browsing, and then click OK.

The steps above applies when you would like to host the My Sites of a particular group of people online.  If you would like to have all the My Sites to be hosted on SharePoint online, you could simply update the My Site host in User Profile Service Application.

  1. On the Central Administration Web site, under Application Management, click Manage service applications.
  2. On the Manage Service Applications page, select the User Profile service application from the list of service applications.
  3. On the ribbon, click Manage.
  4. On the Manage Profile Service page, under My Site Settings, click Setup My Sites.
  5. Update the My Site Host Location with the URL of the My Site Host on SharePoint online, for example:

Please note that the part /PersonImmersive.aspx will make sure the users get to their My Sites directly.  If you only put, the users will be led to OneDrive online instead.  Additionally, in order for the redirection to work completely, you will need to do the following as well:

  • Create an Audience include the users whose My Sites will be redirected.
  • Synchronize user accounts to Office 365.

These topics are not discussed in this post.

Background information:

As Office 365 gains more and more popularity, more and more organization are implementing hybrid model with SharePoint both on-premises and Online. With Microsoft’s announcement on boosting OneDrive for Business to 1 TB, more and more organization would like to adopt Office 365 to provide great capacity for business users while saving IT cost. However, not all the organizations are ready or suitable for hosting their SharePoint environment online completely. Therefore, a hybrid model is the choice of many organizations. Typically, they host their collaborative and publishing sites on-premises for security, compliance reasons or for the flexibility of customization, while My Sites and social features are hosted on Office 365 so they could benefit from large storage capacity as well as up-to-date social features that Microsoft offers.

When Non-Windows Authentication is configured in SharePoint

Windows Authentication is quite popular but in real world, other authentication providers are needed. For example, some organizations require single sign-on (SSO) to provide end users with smooth experience across different platforms. Active Directory Federation Service (AD FS) meets the requirement, working as a shared trusted identity provider for the platforms involved. In SharePoint, it can be configured with Windows PowerShell after setting the SharePoint web applications as a relying party in AD FS. This sounds pretty straightforward. However, we could not get rid of Windows Authentications as crawling requires it.


It is possible to use two authentication providers in the same zone of the same web applications in SharePoint. However, this may not be ideal in the real world as users will be prompted the authentications provider picker before logging in if multiple authentication providers are enabled in the same zone.  For example:


IT managers usually would like to avoid this as end users very likely do not know which one to choose and may get lost, which is not helpful for user adoption. In order to have users authenticated through an authentication provider directly without picking an authentications provider, there can be only one authentication provider in the same zone. Therefore, we need to extend the web applications into a second zone, and use the second authentication provider such as AD FS in that zone and Windows Authentication in the default zone.

You may have a question. Can we put Windows Authentication in the second zone and use AD FS in the default zone? The answer is no. if you crawl a zone of a web application other than the default zone, the query processor does not map search-result URLs so that they are relative to the AAM zone from which queries are performed. Instead, search-result URLS will be relative to the non-default zone that was crawled. Because of this, users might not readily be able to view or open search results. Therefore, when AD FS or any other authentication provider is required in a web application in SharePoint, the zone and authentications provider design would be something like in the table below.


Zone Authentication Provider
Default Windows authentication
Intranet AD FS
Internet Forms-Based Authentication