SharePoint 2010 Standalone Bug

I recently ran the SharePoint 2010 installer, still in Beta, and had no issues during the installation.  My system was configured as a Windows Server 2008 R2 64-bit with a separate Domain Controller.  This was a “clean” server so nothing else was installed.  Next I ran the SharePoint 2010 installer and decided to start by using a StandAlone install, I figured that if this worked then I could proceed to a Farm Installation.

Before I go any further let me commend Microsoft on improving the SharePoint installation process.  I really appreciate the fact that they have now configured the installer to handle installing all pre-requisites instead of just halting and requiring the user to perform these steps.

After the installation completed I ran the SharePoint Configuration wizard, but when I got to the last step I suddenly got an error:

“Unrecognized attribute 'allowInsecureTransport'. Note that attribute names are case-sensitive. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\Profile\client.config line 56) --- \> System.Configuration.ConfigurationErrorsException: Unrecognized attribute 'allowInsecureTransport'. Note that attribute names are case-sensitive. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\Profile\client.config line 56)” I checked the file (client.config) and sure enough the line appears as described in he error message above.  Not sure if the installation was now broken or not I attempted to access Central Admin, SUCCESS.  Next I looked at the SharePoint Web Applications and noticed a Team Site on port 80 had been created.  I checked this site to see if it would work, SUCCESS! Finally I decided to push my luck and see if a Visual Studio 2010 Web Part could be created and deployed to the new SharePoint 2010 environment.  SUCCESS! To date I have not seen any issues resulting from the error message, I am still testing and will update this posting if I run into any issues. UPDATE 11/24 The Microsoft Team has a resolution for the issue described above. [](


More information about SharePoint 2010 Revealed

A fellow SharePointer, Joel Oleson, posted a very nice summary to the recently released SharePoint 2010 system requirements.

Two items have really stood out as I reviewed the information.

First, SharePoint 2010 will require a 64-bit platform to run correctly.  Most likely this is due to limitations of memory and providing enough resources for the SharePoint Web Application Pools.  However, it does seem to follow the recent trend Microsoft has established with the release of OCS R2 and Exchange 2010 which both require 64-bit operating systems.

Second, was the requirement to run Server 2008, 64-bit of course.  This will of course provide the latest version of IIS, but may also be a helpful to Microsoft Hyper-V to start cutting into the VMWare market share.  Given that Server 2008 comes with “free” Hyper-V capabilities why would companies then look to spend additional funds to purchase another virtualization capability.

One last significant advancement from Microsoft that has gone a little under the radar, but I believe is going to be a key capability is the release of Service Pack 2 for the Microsoft Office 2007 suite.  This service pack as attempted to overcome some of the issues experienced when using Office 2007 with SharePoint 2007 that has forms enabled.  Overcoming this issue will be critical as Microsoft has announced that SharePoint 2010’s security will be claims based thus requiring greater support for authentication schemas that do not use Windows Authentication.


SharePoint 2010, or 14 Authentication Revealed

As the SharePoint conference approaches, October this year, we are beginning to look to the next generation of SharePoint and what it will provide and how it will work. Although this is an older article, 10/2007, as we look forward this is going to be a critical change for us to deal with. Microsoft has announced that SharePoint will use “Claims-based authentication” in the next version. This should really not be that surprising, as I have worked with many of their identity and lifecycle professionals they have often pushed away from Active Directory Domain Trusts and encouraged AD Federation, AKA claims-based authentication.
Now we look to SharePoint 2010 to be the next system using essentially Federation of user accounts to perform security activities. The one key thing I will be looking for at the conference is if the Client Integration capability which falls away with SharePoint 2007 through Federated Services is still available in 2010.