This was extremely frustrating while trying to figure it out. Now that I have it is pretty obvious. I was configuring a FAST Search Server 2010 for SharePoint. In the Configuration Wizard at the Server settings screen, it asks for a Server name. The documentation says that this is the FQDN of the server. All my servers have their own name but also have an alias pointing to them. Of course, I always refer to these servers via their alias. So when it asked me for the server name, I naturally entered the alias. The wizard rejects this with a dialog box "Host name validation failed - Please provide a valid server name". I checked firewall settings, event logs and found nothing. It finally dawned on me to actually use the FQDN (easiest way to confirm this is to right click My Computer and select Properties) and it worked.
The strange thing is that if the wizard is able to determine an incorrect FQDN, then why couldn't it just set that value?
Learning how to do things and fix stuff as I go because who really has time to sit in a classroom. Posting it all here because I can not remember it all.
Sunday, May 22, 2011
Tuesday, May 17, 2011
Cannot open database User Profile Service Application_SyncDB ... The login failed
Some of my servers were mysteriously no longer synchronizing the user profiles after some time. Upon further investigation this appeared to happen after a server reboot. Here is an error found in the Application Log with a source of Forefront Identity Manager:
.Net SqlClient Data Provider: System.Data.SqlClient.SqlException: Cannot open database "User Profile Service Application_SyncDB_35eb65afa42c4f8e9ece6a33e9348849" requested by the login. The login failed.
Login failed for user '[my user]'.
at Microsoft.ResourceManagement.Data.Exception.DataAccessExceptionManager.ThrowException(SqlException innerException)
at Microsoft.ResourceManagement.Data.DatabaseConnection.Open(SqlConnection connection)
at Microsoft.ResourceManagement.Data.DatabaseConnection.Open(DataStore store)
at Microsoft.ResourceManagement.Data.TransactionAndConnectionScope..ctor(Boolean createTransaction, IsolationLevel isolationLevel, DataStore dataStore)
at Microsoft.ResourceManagement.Data.TransactionAndConnectionScope..ctor(Boolean createTransaction)
at Microsoft.ResourceManagement.Data.DataAccess.RegisterService(String hostName)
at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.RegisterService(String hostName)
at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.Initialize()
at Microsoft.ResourceManagement.WebServices.ResourceManagementServiceHostFactory.CreateServiceHost(String constructorString, Uri[] baseAddresses)
at Microsoft.ResourceManagement.WindowsHostService.OnStart(String[] args)
A few seconds later in the log
Starting up database 'User Profile Service Application_SyncDB_35eb65afa42c4f8e9ece6a33e9348849'.
So, it looks like the Forefront Identity Manager Service is starting up before SQL has started the necessary databases. This appears to cause it to crash. Now that I figured out the problem, I do a search to figure out how to delay the start of the FIM Service and find this article: Troubleshoot User Profile Synchronization Service start issues (SharePoint Server 2010). Scrolling down to the bottom, there is a section titled "User Profile Synchronization service cannot start after a server restart" This suggests using the Services Manager to change the startup of the FIM services to "Delayed Start". (Note that this contradicts the Important note at the top of the article stating "Starting the FIM services manually or changing the FIM service configuration is not supported.").
.Net SqlClient Data Provider: System.Data.SqlClient.SqlException: Cannot open database "User Profile Service Application_SyncDB_35eb65afa42c4f8e9ece6a33e9348849" requested by the login. The login failed.
Login failed for user '[my user]'.
at Microsoft.ResourceManagement.Data.Exception.DataAccessExceptionManager.ThrowException(SqlException innerException)
at Microsoft.ResourceManagement.Data.DatabaseConnection.Open(SqlConnection connection)
at Microsoft.ResourceManagement.Data.DatabaseConnection.Open(DataStore store)
at Microsoft.ResourceManagement.Data.TransactionAndConnectionScope..ctor(Boolean createTransaction, IsolationLevel isolationLevel, DataStore dataStore)
at Microsoft.ResourceManagement.Data.TransactionAndConnectionScope..ctor(Boolean createTransaction)
at Microsoft.ResourceManagement.Data.DataAccess.RegisterService(String hostName)
at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.RegisterService(String hostName)
at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.Initialize()
at Microsoft.ResourceManagement.WebServices.ResourceManagementServiceHostFactory.CreateServiceHost(String constructorString, Uri[] baseAddresses)
at Microsoft.ResourceManagement.WindowsHostService.OnStart(String[] args)
A few seconds later in the log
Starting up database 'User Profile Service Application_SyncDB_35eb65afa42c4f8e9ece6a33e9348849'.
So, it looks like the Forefront Identity Manager Service is starting up before SQL has started the necessary databases. This appears to cause it to crash. Now that I figured out the problem, I do a search to figure out how to delay the start of the FIM Service and find this article: Troubleshoot User Profile Synchronization Service start issues (SharePoint Server 2010). Scrolling down to the bottom, there is a section titled "User Profile Synchronization service cannot start after a server restart" This suggests using the Services Manager to change the startup of the FIM services to "Delayed Start". (Note that this contradicts the Important note at the top of the article stating "Starting the FIM services manually or changing the FIM service configuration is not supported.").
Friday, May 13, 2011
Managed Service Accounts not supported by SQL Server
I have been setting up a new Active Directory Domain Services running in Windows Server 2008 R2 functional level. According to the documentation What's New in Services Accounts in Windows Server 2008 and Windows 7: "The managed service account is designed to provide crucial applications such as SQL Server and IIS with the isolation of their own domain accounts, while eliminating the need for an administrator to manually administer the service principal name (SPN) and credentials for these accounts." So I create an account to run the SQL services and install SQL server. However, when I try to pick the service account, my SQL user will not show up in the picker at all. Searching around some more, I come across the Managed Service Accounts Frequently Asked Questions (FAQ). It states: "The use of managed service accounts with Microsoft SQL Server is not supported." Argh!
Wednesday, May 11, 2011
Using Alternate Access Mappings to "change" the host header of a SharePoint web application
It looks like there is no easy way to change the host header of a SharePoint web application. This is unfortunate as I want to create many virtual instances of SharePoint and have precanned data for demo purposes. To get around this, I figured I can create the initial copy and then use Alternate Access Mappings (AAM) to provide another way to access my SharePoint sites. It looks like all I have to do is the following:
Here are some references:
MSDN Video: Microsoft SharePoint 2010: Alternate Access Mappings (Level 200)
- Go to Central Administration->System Settings->Configure Alternate Access Mappings
- Select Edit Public URLs
- Change the default setting to the new URL using the new host header
- Go to IIS Manager
- Locate the IIS web site that has the binding for the old host header
- Add a new binding with the new host header
- Go to Central Adminstration->Application Management->Manage Service Applications
- Manage User Profile Service Application
- Click Setup My Sites
- Change the My Site Host location using the new host header
Here are some references:
MSDN Video: Microsoft SharePoint 2010: Alternate Access Mappings (Level 200)
Subscribe to:
Posts (Atom)