SharePoint 2010 Beta on Windows 7

I am happy to say I am now running SharePoint 2010 Beta on my Windows 7 laptop.   I used the handy guide from Microsoft called “Setting Up the Development Environment for SharePoint Server“ for step by step instructions.

There was, however, one small problem.  During the configuration wizard I received the following nasty message:

Failed to create sample data.
An exception of type Microsoft.Office.Server.UserProfiles.UserProfileException was thrown.  Additional exception information: Unrecognized attribute ‘allowInsecureTransport’. Note that attribute names are case-sensitive. (C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14WebClientsProfileclient.config line 56)
Microsoft.Office.Server.UserProfiles.UserProfileException: Unrecognized attribute ‘allowInsecureTransport’. Note that attribute names are case-sensitive. (C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14WebClientsProfileclient.config line 56) —> System.Configuration.ConfigurationErrorsException: Unrecognized attribute ‘allowInsecureTransport’. Note that attribute names are case-sensitive. (C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14WebClientsProfileclient.config line 56)
   at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[] keys, SectionInput input, Boolean isTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult)
   at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult, Boolean getLkg, Boolean getRuntimeObject,Object& result,Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   at System.Configuration.ConfigurationSectionCollection.Get(String name)
   at System.ServiceModel.Configuration.ServiceModelSectionGroup.get_Client()
   at Microsoft.Office.Server.UserProfiles.MossClientBase1.GetServiceBinding(String endpointConfigurationName)
   at Microsoft.Office.Server.UserProfiles.MossClientBase1.GetChannelFactory(String endpointConfigurationName)
   at Microsoft.Office.Server.UserProfiles.MossClientBase1.get_Channel()
   at Microsoft.Office.Server.UserProfiles.MossClientBase1.ExecuteOnChannel(String operationName, CodeBlock codeBlock)
   at Microsoft.Office.Server.UserProfiles.ProfilePropertyServiceClient.ExecuteOnChannel(String operationName, CodeBlock codeBlock)
   — End of inner exception stack trace —
   at Microsoft.Office.Server.UserProfiles.ProfilePropertyServiceClient.ExecuteOnChannel(String operationName, CodeBlock codeBlock)
   at Microsoft.Office.Server.UserProfiles.ProfilePropertyServiceClient.GetProfileProperties()
   at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.RefreshProperties(Guid applicationID)
   at Microsoft.Office.Server.Utilities.SPAsyncCache2.GetValueNow(K key)
   at Microsoft.Office.Server.Utilities.SPAsyncCache2.GetValue(K key, Boolean asynchronous)
   at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.InitializePropertyCache()
   at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.Provision()
   at Microsoft.SharePoint.PostSetupConfiguration.EvalModeProvisionTask.ProvisionServiceApplicationsAndProxies()
   at Microsoft.SharePoint.PostSetupConfiguration.EvalModeProvisionTask.Run()
   at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

After a quick search on Twitter I found a recommendation to just remove the allowInsecureTransport attribute from the client.config file.  I found 2 references to the attribute.  After removing the attribute and then restarting the wizard everything completed successfully.

It is still too early to tell if that change will have a negative impact on some other aspect of the environment.  So far SP2010 seems to be running well.   If I have any problems appear I will post them here.

UPDATE: It appears that there is an issue with WCF and Microsoft is going to provide a hotfix.  They recommend that you do not modify the XML files.  

I did notice that making this change did allow the software to install but Search fails to return results.  There have been posts that you can make a similar modification to the C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14WebClientsSearchServiceclient.config file and search will start working.  I have yet to try this.

If you do make changes you do so at your own risk.  I have backed up any XML files I have modified so I can return them to their original state.

UPDATE 2:  Microsoft has just posted an update for Windows 7 and Windows Server 2008 R2 that resolves this issue.  For me I stopped all SharePoint services, installed the hotfix, and then restarted the services.   Now search is working fine in my environment.   You can download the patch from here: http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=23806

Leave a Reply