Guest Author: Joan Resnick Ehrlich

Continuing with Configure Kerberos authentication (SharePoint 2010) in the SharePoint Server 2010 Library on TechNet, I created the Intranet and My Site web applications. As mentioned in Part 8, for each web application I used a host header and a separate application pool with a unique managed account. I also made sure Kerberos authentication was selected.

Creating a web application from within Central Administration is done via Application Management, Manage Web Applications, New button. Here are the settings I used for the Intranet web application:

As this is a beta, I enabled the Customer Experience Improvement Program. I would not enable this for our production environment.

Creation was successful and I received a message accordingly:

I then repeated the process for the My Site web application, making sure to enter a different Database Name. I kept the default of host header + port number for the virtual directory path (which in the screenshot is not fully visible). For the public URL I could have deleted the port number (80) as I did for the Intranet’s URL above. As port 80 is the default port for http, users do not need to add the port number to the URL. Leaving the port number in or taking it out of the public URL makes no difference when accessing the web applications. Users only need to use a port number when accessing web applications located on non-default ports; that is, located on a port other than 80 for http and other than 443 for https.]

Next up: Creating the site collections, starting with the intranet site. The TechNet documentation (as of this writing) says to select “Collaboration Portal” for the template but there is no such template available for selection. SharePoint Technical Product Manager Bill Baer (MSFT) explained in this forum post http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/057d0264-8df5-4a6f-a39a-8995e56f4d49 that the template has been deprecated and does not show up in the UI, but that it remains as a site definition in 2010 to support MOSS upgrades. I found out via another forum post that it is listed in the output of the PowerShell command Get-SPWebTemplate, which lists all available site definitions.

Coming from WSS I had to do some reading about the enterprise level templates. Which Sharepoint 2010 Site Template is Right for Me by SharePoint MVP Todd Baginski delineates the out-of-the-box site templates and the templates for creating sub sites, pages, and lists that are available by default under each. It came down to Publishing Portal or Enterprise Wiki. The Publishing Portal provides by default only a limited number of site templates for sub site creation but I found instructions for adding the rest at http://praveenbattula.blogspot.com/2010/02/sharepoint-2010-site-templates-not.html, which also notes that the same method can be used for adding page layouts. Here are some more posts on the same topic: Where Are My Site Templates by Sean Earp (MSFT) and http://manish-sharepoint.blogspot.com/2010/03/defining-default-layout-page-for-new.html, which provides step-by-step instructions for adding page layouts.

As we will have mostly read-only pages at the top-level site of our intranet site collection the Publishing Portal seems better suited for our needs. We will create an Enterprise Wiki as a sub site directly below. Here is a screenshot of the Create Site Collection page for the Intranet web application:

After the site collection was successfully created I had to verify that Kerberos authentication was working. Using my Windows 7 laptop I opened the site in Internet Explorer and was greeted by a login prompt. Logging in worked, but how to eliminate the login prompt? Adding the site to the Trusted Sites zone, which is what typically works, did not help. I had to add the site to the Local intranet zone to eliminate the login prompt. [The tip is thanks to a forum post I did not save a link to.] In order to add sites to the Local intranet zone I had to click the Advanced button:

A look at the Security Event Log on the SharePoint server showed that Kerberos authentication was working, so I moved on to creating the My Sites site collection, which proved a bit more complicated. The TechNet documentation says to navigate to the My Site site using the [root] URL and SharePoint will automatically “create a My Site for the logged on user”, after which the “My Site page for that user should render”. Ok, but in what universe? The documentation did not address how to set up My Sites – neither the managed paths nor the root and My Site Host site collections, nor the required User Profile Service Application and its configuration. And since I was strictly following the documentation I had not yet done any of this. Time to make up a Plan B…

I found setting up My Sites a bit daunting. I had read a little bit about My Sites in MOSS but otherwise ignored the feature, and what I knew about My Sites in 2010 was what I had come across when researching other areas. Still on my must read list, which extends beyond SharePoint, is the Social Computing and Collaboration Planning section of Planning and Architecture and My Site settings section of Operations in the SharePoint Server 2010 Library on TechNet. But between SharePoint MVP Liam Cleary’s step-by-step post SharePoint 2010 – My Sites and Jeremy Thake’s SharePointDevWiki post Configure User Profile Synchronization Service I was able to get User Profile Synchronization working and My Sites up and running.

First, I ran the Farm Wizard and created all of the service applications except Lotus Notes Connector. That got me a User Profile Service Application. I then started the User Profile Synchronization service, which starts the two Forefront services visible in the Services MMC snap-in (services.msc) and changes their startup type from Disabled to Automatic. [My understanding is that SharePoint needs to start these services; the services should not be manually started.] The service took a while to start and yes, seeing “Starting…” for an inordinately long time despite a page refresh every two seconds can test anybody’s patience. But once it did the Forefront services showed Started and their startup type had changed from Disabled to Automatic.

Creating a connection to Active Directory was next. The first few times the creation did not take. I was able to populate the “Add new synchronization connection” settings with the AD containers and select the organizational unit (OU) I wanted but when I clicked Ok and was brought back to the Synchronization Connections page the connection did not show up. All I saw was “The query returns nothing” which is the message when no connections exist. An Internet search later and this: http://www.khamis.net/blog/Lists/Posts/Post.aspx?ID=19 led me to figure out that I had to explicitly add the logged in account (spsadmin) as a User Profile Service Application administrator. [I added myself as well so I can also manage connections.] Once I did that and recreated the connection the connection was saved and showed in the Synchronization Connections page. I then started a Full Synchronization. I had selected an OU with four users in it so I expected the synchronization would not take any time at all. Wrong. It took 20 minutes.

After the synchronization finished I created two managed paths for the mysite web application: /my (explicit inclusion) and /personal (wildcard inclusion). An explicit inclusion means only one site collection can be created at that exact URL (in this case, at /my). A wildcard inclusion means many site collections can be created under the specified URL path (in this case, under /personal). Here are explanations of managed paths: SharePoint 101 – Managed Paths by SharePoint Program Manager Zach Rosenfield (MSFT) and http://manish-sharepoint.blogspot.com/2009/02/using-managed-path-with-implicit.html.

Creating the My Site Host site collection followed.  Selecting the /my URL path (Web Site Address section) and the My Site Host template (Template section, Enterprise tab) is the key to success:

Finally, I created a blank site collection at the root URL in order to make the self-service site creation button available in the ribbon on the Manage Web Applications page. I chose the Blank Site template as it seemed appropriate. Note that only the / (forward slash) is chosen in the configurable part of the Web Site Address URL; the / designates the root level.

Once the site collection was created I turned on self-service site creation and set up the My Site parameters in the User Profile Service Application. After that I got a bit lost. I was not sure what URL to navigate to, to create a personal site for myself. I expected my personal site to be created at /personal/USRE_joan, so I navigated to /personal but all I got was a 404 Page Not Found error. I then tried the /my URL which got me to the My Site Host site. I clicked on the My Profile link under my name in the upper right corner, which landed me at /my/Person.aspx?accountname=USRE%5Cjoan. I then clicked back to /my and clicked on the My Content link. SharePoint threw up a message about please wait while it creates my personal site, after which I ended up at /personal/usre_joan/default.aspx. I was getting somewhere but where? My Profile was at the /my URL and My Content was at the /personal URL. Aside from feeling like I was stuck in the Abbot and Costello routine “Who’s on First”, I seriously thought I had a disjointed site. I then clicked on My Network, which landed me at the My Site Host site. It was definitely time for an internet search. Thankfully, I found this rather quickly: http://www.alpesh.nakars.com/blog/set-up-my-site-in-sharepoint2010/. A close look at the enlarged screenshots showed that my URL setup matched. So I guess My Sites is set up correctly after all and I just need to do a bit of reading to understand the reason two URL paths are used for a user’s My Site.

I should note that during the personal site setup process I received this message, to which I clicked No, as it took me by surprise and I first want to research the feature:

The final step in the TechNet documentation was to confirm Search Indexing and Search Query functionality worked correctly. I uploaded a document to the Press Releases Documents library, as good a place as any to test, and initiated a full crawl from the Search Service Application in Central Admin. The crawl completed successfully, but a search for the document did not turn up any results. Reading through the Post-installation steps for Search instructions under the Initial Configuration section of the SharePoint 2010 Library I realized that the Intranet site did not have a “tab named Search Center”. So I created a Search Center site as a sub site under the Intranet root site. This is the structure we will use in production rather than a dedicated site collection specified in the aforementioned documentation. I used the Enterprise Search Center site template, which provides People search; the Basic Search site template does not. If you do not see the Enterprise Search Center site template, http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/03/11/dude-where-s-my-search-center.aspx steps through how to make it available. After the sub site was created, “Search Center” showed up in the Intranet home page Quick Launch. No top navigation tab but good enough. I then specified the Search Center site path in the Intranet’s Site Settings, Site Collection Administration, Search settings and initiated another full crawl. This time my uploaded document appeared in search results.

With Search Indexing and Search Query functionality verified I had completed the Configure Kerberos authentication (SharePoint 2010) documentation. I’ll leave the rest of search configuration for the RTM. Incidentally, I noticed that there is no breadcrumb navigation or any other visible means of navigating away from the Search Center site other than using the browser’s Back button. Changing the Navigation settings had no effect. I have also since noticed that a “Search” sub site (also without visible means of navigation) already existed under the Intranet root site and that it was created when I created the Intranet site collection. The site template that was used appears to be the Basic Search site template, because “People” is not an available search option.

Now that SharePoint 2010 RTM is available I will not be continuing with the Beta. As soon as SQL Server 2008 R2 RTM is available I will reformat the servers and install the RTM versions. I will report on the differences, if any, from the Beta installation in my next article.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

In my last article I left off ready to configure Search services, as specified by Configure Kerberos authentication (SharePoint Server 2010) in the SharePoint Server 2010 Beta Library on TechNet.  The documentation’s example scenario calls for the Index and Query services to be on dedicated servers. I had only my one SharePoint server and so adjusted the instructions accordingly.

I was first supposed to start the “SharePoint Foundation 2010 Search service”. Services can be reached via Central Admin, System Settings, Manage services on server. I did not see a service with that exact moniker but rather, a “SharePoint Foundation Help Search” service and so started it. I had not paid attention to Foundation Search in the first SharePoint go-round but had focused solely on the Server Search service application. I had assumed that Server Search replaced Foundation Search which, like WSS 3.0 Search, is limited in scope to the site collection level. To be honest, because of the name mismatch I was not sure Foundation Help Search was the same service as Foundation 2010 Search. (A perfect example of either literal thinking or thinking too much into something) A search on the former did not turn up useful information and a search on the latter was not much more helpful. I assumed the services were one and the same and continued with the configuration. Afterwards, I did a bit of investigating which I will explain later.

When starting the Foundation Help service I was presented with the configuration screen shown below. I used spssearch as the Search service account and a separate, dedicated domain account, spscrawl, for the Content Access Account, which I had not planned for and had to create on the spot. The Content Access Account (aka crawl account) is granted Read access to all SharePoint content. I left the defaults for the SQL server and Search database name. I also left the default indexing schedule, which I can adjust later.

Next up: Starting the SharePoint Server 2010 Search service, which is listed as “SharePoint Server Search" directly below the SharePoint Foundation Help Search:

Rather than opening the “subsequent page” described by the TechNet documentation, clicking Start merely produced the message shown below about needing to create a Search Service Application. I was not surprised at the apparent discrepancy between the 2010 Beta documentation and the Beta software. Certain parts of the documentation appear to be forklifted with little or no editing from MOSS documentation. But both the 2010 software and documentation are still being finalized; let’s wait to see the RTM.

I decided to manually create the Search service application (as the message describes to do) rather than use the Farm Configuration Wizard. [In Part 7 of this series I said I used the Wizard to create all service applications. This was the one exception I forgot to mention.] I wanted to configure dedicated web application pools and because I had not had the “Stopped” proxy issue with Search in the last go-round I felt confident I would not in this go-round. I decided to first register spssearch as a Managed Account, although I could have done so from the Create New Search Service Application page. I saw that configuring Foundation Help Search had already registered spssearch:

I continued with creating the service application, as shown in the screenshot below. I created separate, dedicated web application pools for the Search Admin Web Service and Search Query and Site Settings Web Service. I later came across TechNet: Deployment Scenarios: Multiple Servers for a Three-Tier farm: Create and Configure a New Search Service Application, which says to use the same application pool for both services. Does it matter? When I run into an issue that leads back to using separate application pools I’ll have my answer.

I used spssearch as the account for the Search Service and both web application pools. The TechNet documentation scenario calls for a separate crawl account. In the scenario the account name used is mosscrawl and it is a different account than for Foundation Search, which is named wsscrawl.  But the documentation never specifies where to use mosscrawl. As I found out by viewing the default settings on the Search Administration page after creation, the Search Service Account is by default used as the crawl account and as such, added to the Full Read policy of the Intranet and My Site web applications when these were created.

Thus, both spssearch and spscrawl were added to the Full Read policy for both web applications. Jumping ahead, here is a screenshot for the Intranet web application User Policy settings:

I do not see why two separate crawl accounts – one for Foundation Help and one for Server Search – are needed. I can see why the crawl account should be different than the Search Service account because the latter is used for web services. Oh well, another item for the RTM question list.

The Search Service application was created successfully. The application, its proxy, and the Server Search service all showed “Started”. The following databases were created in SQL:

And one database that resulted from starting and configuring Foundation Help Search service was also created:

I did not further configure the Search Service application, preferring to first complete the steps in the TechNet documentation.

As mentioned earlier, I did a bit of investigating into the name discrepancy between Foundation 2010 Search and Foundation Help Search. A look at the Services MMC snap-in (services.msc) shows a “SharePoint Foundation Search V4” service directly above SharePoint Server Search 14: (For the unfamiliar, V4 and 14 indicate the 2010 versions.)

I thought I would conduct an experiment by attempting to stop the Foundation Help service in Central Admin and see if Foundation Search V4 showed stopped in the Services MMC snap-in. But I got this message and decided against it:

I attempted the opposite: stopping the Foundation Search V4 service in the Services MMC snap-in. When I refreshed the Manage services on server page in Central Admin the Foundation Help Search service still appeared as “Started”. You would think I was onto something, but I then attempted the same experiment with Server Search. Attempting to stop Server Search in Central Admin produced this ominous message:

So I again did the opposite – stopped the Server Search 14 service in the Services MMC snap-in – with the same result: that service in Central Admin also still appeared as “Started”.

I then took a closer look at the service descriptions in the Services MMC snap-in. The description for the Server Search 14 service does state that it replaces Foundation Search for searching user content:

But here is the Foundation Search V4 service description:

Obsessively detail oriented that I am I noticed the description for Foundation Search also includes “help content” whereas Server Search does not. Either two different people wrote the descriptions or Foundation Search provides the help content for all SharePoint 2010 editions and perhaps that is how the service name in Central Admin came to be. I did find this TechNet document SharePoint Foundation 2010 Search is not running (SharePoint 2010 Products) in the Technical Reference, System Center Operations Manager knowledge articles section of the SharePoint Server 2010 Library as well as the SharePoint Foundation 2010 Library. The document’s location in both libraries seems to indicate the Foundation Search service is important in all SharePoint 2010 editions.

Both services use the mssearch.exe executable. Server Search 14 uses the one in the Program Files\Microsoft Office Servers\14.0\ Bin folder. Foundation Search V4 uses the one in the Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Bin folder.

Researching online brought me to an answer in a forum post, by MVP Mike Walsh (WSS FAQ sites:  WSS v3 FAQ and WSS v4 FAQ – great stuff) who explained the purpose of the WSS Search database in a MOSS system: http://social.technet.microsoft.com/Forums/en-US/sharepointsearch/thread/831bce3d-2fd0-484c-b827-a4c3b40980e1. The WSS Search database indexes Help content and MOSS Search indexes all other data. I also came across the K2Distillery article I cited in Part 7, which I reread and found the same applies for 2010. Information overload, when a human only has so many brain cells, leads to information being dropped from memory. But I have my answer and I have useful information I may otherwise not have known that might come in handy when troubleshooting.

Next up: Creating the Intranet and My Site web applications and site collections and testing Kerberos authentication connections.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

Before proceeding with the next step in the TechNet article Configure Kerberos authentication (SharePoint 2010), configuring Search, I opened Event Viewer and reviewed the Application and System event logs for errors and warnings. I also reviewed the Operational log that SharePoint adds to Event Viewer. This log, highlighted in the screenshot below, can be found under Applications and Services Logs:

The Applications and Services Logs is a new category of logs beginning with Windows 2008 and Vista. Also new is the Custom Views category of logs. The revamped Event Viewer makes it easy to create a permanent custom view of filtered events and these are stored under the Custom Views section. Here is the Create Custom View dialog box:

One custom view is provided by default; this is Administrative Events, which a view of “Critical, Error and Warning events from all administrative logs”. In addition, when a server role is installed a related custom view is added under the Server Roles section of the Custom Views category; at least this has been my experience. I have found too that the logs for some server roles, though not all, will also appear under Applications and Services Logs category; that is, in both sections. For example, on my domain controllers, the DNS and Active Directory Services logs appear under both sections.

I found several warnings and errors, outlined below:

System Event Log:

Only a few and familiar errors:

• Event ID 5048 (Source: WAS) about the invalid AppPoolID for the Security Token service web application pool appeared as expected and as described in Part 7 of this article series.
• There was also Event ID 10016 (Source: DCOM), another error I was familiar with:


Not only has this error occurred with every SharePoint 2010 Beta install that I’ve done, it also occurred on our WSS 3.0 server oh-so-long ago.  In fact there is a KB about it: Microsoft KB 920783.The fix was straightforward: use the Registry to identify the application with the CLSID cited in the Event, by searching for the CLSID in HKLM (HKey_Local_Machine). Then find the application in the Component Services MMC snap-in and grant Local Activation permission to the user account cited in the Event. Windows Server 2008 R2 threw a bit of a wrench into it, though. On Windows Server 2003 my domain admin account sufficed to change Local Activation permissions. On Windows Server 2008 R2 the DCOM controls were greyed out (not editable). An Internet search turned up the answer: due to increased security even domain admins do not have permissions to perform certain functions; editing DCOM permissions is one such function. The search also provided the solution, which SharePoint MVP Wictor Wilen describes in his blog post Fix the SharePoint DCOM 10016 error on Windows Server 2008 R2.

The solution changes the Owner on the CLSID registry key. I was uncomfortable leaving the change so once I had completed the fix I reset the Owner back, though not without some Laurel and Hardy moments.  The original Owner is TrustedInstaller. This is a local account and the proper account name is NT SERVICE\TrustedIntaller.  To make a long story short, I had to manually type in NT SERVICE\TrustedInstaller as shown in the screenshot below rather than use the Advanced… button to search for the account. The account won’t show up in a query.

Application Log

There were also some warnings and errors in the Application Event Log:

• Event ID 8059 (Source: SharePoint Foundation) about configuring alternate access mappings (AAM) for the Central Admin site:



Adding AAMs is done via Central Admin, System Settings, Configure Alternate Access mappings. I clicked the Central Admin site, then clicked “Edit Public URLs” and added the FQDN URL for Intranet zone mapping:




After which the AAM list for Central Admin showed:



• Event ID 7043 (Source: SharePoint Foundation) for the Taxonomy Picker web control. This error has occurred with all SharePoint 2010 installs I’ve done and is a known issue in the Beta:



And for the Scenario Navigation web control, which also has repeated with each installation:




I recently came across the reasons for the two errors in a forum thread: http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/c894d98c-24ab-416c-aca9-ae57644deb5e. Look for the reply by Koen van der Linden which relates directly to these errors. Apparently, the errors are caused by code errors.

• Event 7362 (Source: Web Content Management)



I have not done this yet for the new install but did so at work for the original install. This necessitated yet another domain user account (the list keeps getting longer), which I named portalsufull.

• Event 5586 (Source: SharePoint Foundation)



Followed by two of:




This repeated once immediately in succession but not again.

• Event  8193 (Source: VSS)



The full error details show the error is related to SPSearch4 VSS Writer. This error has repeated intermittently days apart but I do not see a pattern. I will wait to see if the error repeats in the RTM.

One error I did not get but had gotten previously at home (pre-reformat) and at work the day after installation was a dreaded “Server Error in ‘/’ Application” when trying to open Central Admin:

At first I panicked and rebooted, and that worked. But the next day the error returned. So, reacting a bit more calmly this time I followed the instructions in the error message to turn customErrors mode to Off. Rather than edit the original web.config file, I made a copy to another location and edited the copy. I then renamed the original web.config file, moved the copy and used it. I use this method because when I first started with WSS I had an ugly experience editing the WSS web.config file on our test server – WSS got hosed – and reversing the changes did not undo the damage. Perhaps the file got corrupted. Fortunately I had first made a copy and so was able to use the copy.

With customErrors off, launching Central Admin brought up an error I could research:

Doing so led me to the solution: SharePoint 2010 beta error: Retrieving the COM class factory for component with CLSID {BDEADF26-C265-11D0-BCED-00A0C90AB50F} failed due to the following error: 800703fa by Microsoft Consultant Bassem Georgi.  So I went into IIS, selected the Central Admin web application pool, Advanced settings and set Load User Profile to True:

With none of the errors fatal, I proceeded to configure Search, which I will step through in Part 10.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

Kerberos is a network authentication protocol developed by MIT and named after the three-headed dog in Greek mythology, Kerberos. The Latinized name is Cerberus. For an explanation of the protocol see TechNet: Kerberos Explained and Wikipedia. For those who are curious about the dog, see Wikipedia with pictures. Kerberos has been a standard in Windows operating systems since Windows 2000 and the default used in Active Directory environments. Prior Microsoft operating systems used Microsoft-proprietary protocols, LM (LAN Manager) and its successor NTLM (NT LAN Manager) followed by NTLMv2. For information on NTLMv2, hereafter referred to as NTLM, see MSDN: Microsoft NTLM.

Kerberos is more secure than NTLM, as are other protocols available for use in current versions of Windows. For a list see Windows Authentication in the Windows Server 2008/2008 R2 TechNet Library. As that documentation explains, NTLM is still supported, used for authentication in workgroups and standalone systems (non-domain environments), and generally used as a fallback if Kerberos cannot be negotiated. Kerberos-only authentication can be forced so that authentication will fail if Kerberos is not negotiated, though I gather from my reading this depends on the application and application version. Too – I learn something new every day – beginning with Windows 7 and Windows Server 2008 R2 you can restrict NTLM authentication usage (Introducing the Restriction of NTLM Authentication). Finally, Microsoft has continually enhanced Kerberos authentication in Windows.

SharePoint can be configured with NTLM or Kerberos authentication. NTLM works out-of-the-box but there are additional steps required to make Kerberos work. And there are zillions of folks (or so it seems) who have either blogged about how difficult it is to get Kerberos to work with MOSS or have blogged about how to do it because of the difficulty. I’ve read that Kerberos configuration in SharePoint 2010 has been made easier, but I have no experience with MOSS as a reference and have not had to configure Kerberos until now. In our production environment as in our test environment SQL Reporting Services will not be on the same machine as SharePoint.  Kerberos is needed because of the “double-hop” authentication scenario; one hop to the SharePoint server and a second hop to the SQL server. NTLM authentication will inherently fail. (A thank you to the SharePoint911 team for that information during an “Ask the Experts” web session I attended.)

Prepping for Kerberos authentication

An “Aha!” experience can come with simply reading about something. Or not. With Kerberos authentication I understood the concept right enough from the reading but the configuration know-how needed the doing. It was much easier than I expected once I clearly understood what was needed and what to do. To configure SharePoint 2010 with Kerberos authentication I followed the guidance provided by Configure Kerberos authentication (SharePoint Server 2010) in the SharePoint Server 2010 Beta Library on TechNet. Here are the steps I took on my reformatted home server after installing SQL Server but prior to installing SharePoint 2010. All service accounts previously created still existed in Active Directory and so I simply reused them.

1. Created an SQL Server login for the spsadmin domain account which will be used to install and configure SharePoint, and then added the login to the DBCreator and Security Administrator roles. This is a general SharePoint requirement.
2. Added the spsadmin and spsfarm domain accounts to the server’s Local Administrators group. At work, being that SharePoint and SQL Server are on two separate servers I would add the accounts to each server’s group. This step is not in the TechNet documentation but sidesteps any installation issues due to insufficient privileges on the servers. The accounts can be removed later.
3. Decided to run the My Sites and Intranet application pools each under a separate domain account rather than the spsfarm account, and created two users accounts in Active Directory, spsmysitepool and spsapppool, respectively. (The latter in hindsight should have been more appropriately named.)

4. Made a list of the Service Principal Names (SPNs) that will be needed, matched to the domain accounts on which the SPNs will be set. In our Beta scenario SPNs are needed for the SQL Server instance and the Central Admin, Intranet, and My Sites web applications. SPNs for both the FQDN and NetBIOS host names had to be constructed. [MSDN: Name Format for Unique SPNs explains how an SPN is constructed.] The corresponding matching accounts on which the SPNs will be set are sqlservice, spsfarm, spsapppool, and spsmysitepool, respectively.

   Real or virtual host names can be used to construct an SPN. The TechNet documentation addresses both. The Central Admin web application uses the actual server name; hence the server name is used to construct the SPNs. For the Intranet and My Sites web applications I will use host headers.  We need to use host headers because we will host the My Sites site collection in a separate web application than the Intranet site collections and we want SharePoint 2010 Search to crawl both web applications. The TechNet documentation explains that SharePoint 2010 Search can crawl web applications configured to use Kerberos authentication only if the web applications are hosted on IIS virtual servers that are bound to port 80 or port 443 (HTTP default ports). Using host headers allows us to use the same IP address and port for both web applications. This is the first time I will configure host headers.

5. Set the SPNs. The SPNs are set on the servicePrincipalName attribute of the domain accounts. [User accounts are a type of object in Active Directory. Examples of other types of objects are computers, printers, and groups. Objects have attributes. servicePrincipalName is one of the attributes of user and computer objects.] Setting an SPN can be done using a command line tool, setspn.exe, or the Active Directory MMC snap-in ADSI Edit. Using ADSI Edit incorrectly can hose Active Directory. I first used it out of necessity and by now am comfortable with it (not to mention extremely careful to cancel out when not making a change). I wanted a visual peek, so ADSI Edit is what I used. Here are screenshots of the SPNs being set on the different accounts:
• sqlservice account:
  [MSSQLSvc is the service name for the SQL default instance MSSQLSERVER. See SQL BOL: Registering a Service Principal Name for information on configuring SPNs for SQL Server 2008 and 2008 R2.]


• spsfarm account:
  [The TechNet documentation calls for SPNs constructed with the Central Admin port number. However, I later found that until I also added SPNs without the port number I could not access Central Admin from a computer other than the server hosting Central Admin. That tip came from a forum thread I did not keep a reference to, but thank you. The screenshot is post-addition.]
  
  

  The host name is the same as that used in the SPNs for sqlservice only because the SharePoint Central Admin and SQL servers are one and the same.

• spsapppool account:



• mysitepool account:


6. Tested and verified Kerberos authentication is being used when connecting to SQL Server from a SharePoint 2010 server. I first waited for the AD changes to replicate to my other domain controller. This step is not in the TechNet documentation but ensures that the domain controller authenticated against has the AD changes. Methods to test SQL connectivity include SQL Server Management Studio and the SQL client connectivity tool SQLCMD. As my home server is both SQL and SharePoint, testing posed a problem. I had the SQL Server DB Engine installed on my Windows 7 laptop so I used Management Studio on the laptop to connect to the server. I then checked the Security log on the server for a successful logon event and verified that Kerberos authentication was used. The TechNet documentation references Event ID 540; that Event ID is for Windows Server 2003. For Windows Server 2008 and 2008 R2 the Event ID is 4624. Here is the pertinent output from the event:





Randy Franklin Smith’s Ultimate Windows Security site has a Windows Security Event Log Online Encyclopedia that always comes in handy.  Here is the information for Event ID 4624. “NULL SID” in the Subject: Security ID field looks disconcerting but Microsoft provides this description in the event: “The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.” The Ultimate Windows Security event description indicates that NULL is a common value and the field is “not usually useful information.” The information contained in the Logon Type, New Logon, and Detailed Authentication Information sections provided the critical information and confirmed that Kerberos authentication was being used.

Prepping for SharePoint 2010 Installation

I was now ready to install the SharePoint 2010 Prerequisites, so I logged onto the SharePoint server from this point on as spsadmin. I decided to first install the Reporting Services Add-in for SharePoint 2010, which is a separate download from Microsoft. The RS Add-in can be installed before or after SharePoint is installed. TechNet: Using Access Services with SQL Reporting Services: Installing SQL Server 2008 R2 Reporting Services Add-In (SharePoint Server 2010) states that installing the RS Add-in prior to installing SharePoint 2010 means less steps. The installation process was a handful of screens and decision-free. A successful installation reported Event ID  11707:

After installing the RS Add-in I ran the SharePoint 2010 Prerequisites setup, installed the WCF fix, and rebooted.  The SharePoint 2010 installation and configuration followed.

Installing SharePoint 2010 and Running the Products Configuration Wizard

Installation

Installation is run on all of the SharePoint 2010 servers that will be in the farm before the Products Configuration Wizard is run. The SharePoint 2010 files (binaries) are installed and a few choices made:

 “Server Farm” for Installation type: (Ignore that the Standalone option is highlighted.)

“Complete” for Server Type:

File Locations for the SharePoint 2010 files and Search index files: (Note the warning about the index files location.)

Products Configuration Wizard (PSConfig UI):

The Products Configuration Wizard executable is psconfigui.exe and often referred to as PSConfig UI. The PSConfig command line tool executable is psconfig.exe and commonly referred to as PSConfig. This article deals with the Wizard UI only.

PSConfig UI is run first on the SharePoint server that will host the Central Administration site and then on all other SharePoint servers. When PSConfig UI is first run the option to “Create a new server farm” is selected. Only one server in a farm hosts Central Admin but you can later change which server. PSConfig UI creates the SharePoint_AdminContent<GUID> database which stores Central Administration site content. [GUID = Globally Unique Identifier. Here’s an easy-read explanation of a GUID: http://betterexplained.com/articles/the-quick-guide-to-guids/] PSConfig UI also creates the SharePoint_Config database which stores all configurations for the farm. SharePoint Technical Product Manager Bill Baer provides a brief description of these and the other SharePoint 2010 databases in his Introduction to the Microsoft SharePoint SharePoint 2010 Database Layer blog post.

Running PSConfig UI on the SharePoint server that will host Central Admin:

I created a new server farm:

Provided the database server and left the default name for the SharePoint configuration database. Used the farm account as the account to be used to connect to the configuration database from this server:

Set a passphrase, which is later needed when adding servers to the farm:

Set a port number for the Central Administration web application. A random port number is presented but can be changed.  And – Alert! – selected Kerberos as the authentication method:

After which I received this warning, to which I clicked Yes:

Verified all settings chosen were correct:

The Wizard completed successfully:

I then clicked Finish and Central Administration launched successfully. The next step was to verify that Kerberos authentication was being used to log on to Central Admin. This needed to be done as spsadmin from another SharePoint server. Lacking another SharePoint server I again used my Windows 7 laptop, which is when I discovered I needed to add SPNs without port numbers to the spsfarm account servicePrincipalName attribute, as I had described earlier. Until I added those SPNs a logon prompt would appear and any credentials entered would fail.

Running PSConfig UI on all other SharePoint servers

At this point, had I additional SharePoint servers to configure I would have run PSConfig UI on these servers, selected “Connect to an existing server farm”, and entered the passphrase when requested. On the “Completing the SharePoint Products Configuration Wizard” screen I would have selected the Advanced Settings button and verified that “Do not use this machine to host the web site” was selected:

Reconfiguring SharePoint to work with Kerberos post-installation

SharePoint can be reconfigured with Kerberos authentication post-installation if NTLM was initially selected. We would have attempted this at work, except we decided to switch SQL to a different physical server with more RAM and so blew away the existing installation and started over with Kerberos.

Installing SharePoint on the SQL Server at work

We were required to install and configure SharePoint on the SQL server at work. This was necessary because the server with the instance of SQL Reporting Services in SharePoint integrated mode needs to be joined to the farm. This step is not necessary if the RS instance is installed on a SharePoint server. [Licensing costs dictated our setup.]

We did run into a bit of difficulty. We used SQL Server 2008 R2 BOL: How to install a SharePoint Web front-end on a Report Server. The documentation specifies (as of this writing) to select “Advanced” for Installation Type and “Web front-end” for Server Type during installation. As you can clearly see from the previous screenshots those options are not there. What to do?

One post to the Microsoft SharePoint 2010 – Setup, Upgrade, Administration and Operation later, we had our answer for the Beta thanks to SharePoint MVPs Paul Stork and Todd Klindt: Choose Server Farm, Complete. The only difference between Complete and WFE-only is the number of binaries copied to the server. If you do not start the services on that server in Central Admin SharePoint will then ignore those services. Todd Klindt said he read that a WFE-only role can be scripted from the command line and that one of the example config.xml files might be WFE-only. I went looking for the example config.xml file, had no clue what to look for, realized I probably should be looking in the installation executable, extracted that, and found some config.xml files in the “Files” folder subfolders related to installation type but no WFE-only. So we installed SharePoint on the SQL server using the same process as for installing and configuring SharePoint on additional servers, making sure to verify that the server was not selected to host Central Admin. We will wait for the RTM to see if the WFE-only option is eliminated or added back into the PSConfig UI or provided via scripting, and whether the documentation is updated accordingly and/or the community blogs about it. We left the SharePoint services running on the SQL server until we configure RS-SharePoint integration; perhaps then we can figure out which if any services can be stopped. I prefer only as much SharePoint on the SQL Server as is necessary for Reporting Services to work.

In Part 9 of this series I will enumerate the warnings and errors that appeared in the Event Logs post-installation and explain the steps I took to resolve them when possible. Part 10 will pick up with the next step in the TechNet documentation, Search configuration. Part 11 will walk through the final steps: creating the Intranet and My Site web applications and site collections.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

The SharePoint 2010 Beta installation and product configuration went smoothly. There is not much to the process, which is rather straightforward. We ran into a show stopper post-installation when manually creating a few of the service applications. The problem also occurred on my home server, leading to a reformat/reinstall of that server as part of the troubleshooting process. That in turn led to an opportunity to install SharePoint using Kerberos authentication following the TechNet instructions here: Configure Kerberos authentication (SharePoint Server 2010), which I will step through in my next article. This article will explain the post-installation show stopper and subsequent troubleshooting. “Fasten your seat belts, it’s going to be a bumpy night.” (Said the late, great actress Bette Davis as Margo Channing in the 1950 movie classic “All About Eve”.)

Each instance of a service application has a service application proxy. This is part of the new shared service architecture in SharePoint 2010 which replaces the Shared Service Provider (SSP) architecture in MOSS. Several articles and blog posts later (links provided at article end), a few SharePoint Conference 2009 sessions, and one free (OMG, free) Critical Path Training webinar by principal owner and SharePoint MVP Andrew Connell, I think I understand the service application-proxy relationship. Using one service application instance and one web application as an example, keeping in mind that a service application can be associated with many web applications and a web application can have one or more instances of that service application:

A service application provides a service. “Consumer objects” on the web front end (aka inside a web application) consume the service. A consumer object is any SharePoint feature that provides functionality to the user; examples are web parts and code. Consumer objects do not communicate directly with the service application but rather, connect to the service application’s proxy, which also resides in the web application. It is the proxy that connects to and communicates with the service application. Now, here’s where it gets a bit complicated. The proxy knows it is associated with the service application but not on which application server the service application resides. The service application can reside on one or more application servers. (Think scaled-out deployments.) So the proxy asks SharePoint where its service application is. SharePoint knows which application servers host that service application. If the service application resides on more than one application server in the farm, SharePoint determines which server is next in line to handle a request (in a kind of round robin load-balancing way) and tells the proxy. The proxy then communicates with the service application on that server. The proxy passes the request from the consumer object to the service application. The service application handles the request and passes the results back to the proxy which passes it back to the consumer object.

Hopefully my communiqué is more “By George, she’s got it” (My Fair Lady – must be old movie night on the brain) than not. The gist is, proxies are a critical piece to the architecture.

Well, then… after manually creating the Excel Services and Access Services service applications, the corresponding proxies showed a “Stopped” status. So too did the proxy for the “WSS_UsageApplication” service application. Given a proxy’s role, this was Not Good. The show stopper? We could not figure out a way to start the proxies and nothing we tried worked. Not good at all.

A screenshot of the Excel Services and Access Services proxies showing “Stopped”:

The WSS_UsageApplication proxy also showing “Stopped”:

We had created the Excel Services and Access Services service applications in Central Administration via the Manage Service Applications “New” menu. Most service applications can be manually created this way. PowerShell can also be used.

Here is the “Create New Excel Services Application” settings page:

As the screenshot indicates, we used a new, dedicated application pool and dedicated managed account. We did the same for Access Services and all other service applications listed in the menu, which offer the same opportunity.

There are by my count – and it sure is hard to keep count – five service applications not listed in the menu but when created are listed on the “Manage Service Applications” page. Two are automatically created and configured by SharePoint when a farm is created. These are the Application Discovery and Load Balancer and Security Token service applications. You should therefore see these listed on the Manage Service Applications page when first launching Central Administration.

The other three are the Application Registry Service, State Service, and Usage and Health data collection service applications. All three can be created using the Farm Configuration Wizard. In fact, we could not find a way to create the Application Registry Service other than the Wizard, which in the end is how we did create it. PowerShell stumped us. We did not see a directly related “New-” command, e.g. “New-SPApplicationRegistryApplication”, or even a general “New-” command, e.g. “New-SPServiceApplication” to use. As it ends up, we don’t need the service because we have WSS only. The service provides backward compatibility to the SharePoint 2007 (MOSS) Business Data Catalog (BDC). In doing research for this article I found out that “Application Registry” was the original term for the BDC and the BDC is referenced internally (API, Object Model) by that term. (And do we all know that in 2010 the BDC has been renamed Business Data Connectivity and is part of the Business Connectivity Services (BCS) architecture?)

The State Service and Usage and Health data collection service applications can be created using PowerShell (New-SPStateServiceApplication, New-SPUsageApplication). We used PowerShell for the State Service. The Usage and Health data collection can also be created by using the “Configure usage and health data collection” link under Reporting in the Monitoring section in Central Admin. We used the link, which we discovered by following the instructions in Initial configuration under Configure farm services  in the SharePoint Server 2010 TechNet Library.

This leads to an interesting digression. Configuring usage and health data collection using the link created the WSS_UsageApplication service application. When we later ran the Farm Configuration Wizard (to create the Application Registry service application) the selection box for “Usage and Health data collection” was checked and greyed out, as is the case after the first instance of a service application is created. When I redid my home server I let the Farm Configuration Wizard create all service applications, including Usage and Health data collection, as part of the troubleshooting process. Instead of the expected WSS_UsageApplication, a “Usage and Health data collection” service application resulted:

Clicking the “Usage and Health data collection” service application led to the same configuration page as did “WSS_UsageApplication”. What’s with the name difference? I haven’t a clue.

Anyway, I could not find within Central Admin how to start a proxy separately from its service application, nor could I find a PowerShell command (did I miss it?).  So I resorted to working with the service application. I tested first with Excel Services and this is what did not work: stopping and restarting the service, using the farm account instead of a dedicated account, and using a new application pool. Resetting IIS and rebooting did not work. Deleting/recreating the service application, deleting/recreating the service application using a new name, and creating a second instance (first removing the first instance from the default proxy group) also did not work; with each new instance the proxy showed “Stopped”. (I suppose that means I was able to recreate the issue on demand.) I tested next with Access Services but after deleting/recreating once with no luck I gave up. (Glutton for punishment I am not.)

I did an exhaustive search online which turned up empty except that I determined we are one of four people in the entire world to have experienced this issue. I posted to the Microsoft SharePoint 2010 – Setup, Upgrade, Administration and Operation forum. Except for my own blethering updates as I worked through the issue the post went unanswered, perhaps because no one knew what to make of it (or me).

I did not think the issue was related to installation but to the manual creation process. Because I was not sure whether the manual creation process was the cause – the other service applications’ proxies did not experience the issue – I decided to start over with a clean slate. Hence, the reason I reformatted my home server and used the Farm Configuration Wizard right out of the gate to create all of the service applications. Voila! That worked. All proxies showed “Started”.

Poking around, I saw that the Excel Services and Access Services service applications had been deposited by the Farm Configuration Wizard into the “SharePoint Web Services Default” pool. This can be seen via the Security, Configure Service Applications page:

Spencer Harbar calls this application pool “the big Daddy” because this is the pool in which all of the service applications are placed when the Farm Configuration Wizard is run. Take a read of his articles SharePoint Server 2010 Worker Processes and More on SharePoint 2010 Application Pools.

Another side note but “quite important in the scheme of Beta things”: I found Mr. Harbor’s blog when researching Event ID 5048 from WAS (Windows Process Activation Service) in the System Event log, which I noticed when the SharePoint Product Configuration Wizard finished:

The error referenced the Central Admin web application pool. Mr. Harbor explains the error and provides the fix here: Application Pool Mis-configuration in SharePoint 2010. I have had to apply the fix for each web application after creation.

As for resolving the stopped proxy problem at work, I decided to attempt a less drastic approach rather than reformat/reinstall. I deleted the troublesome service applications (rebooting the server after) and recreated them using the Farm Configuration Wizard. That also worked; the proxies showed “Started”. The next troubleshooting step would have been to change the service applications’ configuration to use a dedicated application pool. I chose not to bother for the Beta.

Here are the links to articles and blog posts about the SharePoint 2010 service application architecture. There are numerous more; just search on “SharePoint 2010” and (“service application architecture” or “service application framework” or “shared service”). Don’t forget TechNet and MSDN.

SharePoint 2010 Shared Service Architecture Part 1 by the Microsoft SharePoint Escalation Team:
http://blogs.msdn.com/spses/archive/2010/01/20/sharepoint-2010-shared-service-architecture-part-1.aspx

SharePoint 2010 – New Shared Services by James Kemp, Microsoft Consulting Services, UK SharePoint team:
http://blogs.msdn.com/uksharepoint/archive/2009/10/21/sharepoint-2010-new-shared-services.aspx

The New Service Application Architecture in SharePoint 2010 by Andrew Connell:
http://www.andrewconnell.com/blog/archive/2009/10/19/the-new-service-application-architecture-in-sharepoint-server-2010.aspx

SharePoint Service Applications by Ted Pattison (also a Critical Path Training principal owner and SharePoint MVP):
http://www.sharepointproconnections.com/article/sharepoint-development/SharePoint-Service-Applications.aspx

SharePoint 2010 Service Architecture and Logical Architecture by Jason Apergis
http://www.k2distillery.com/2010/01/sharepoint-2010-service-architecture.html
http://www.k2distillery.com/2010/03/sharepoint-2o10-logical-architecture.html

Planning for the New Service Application Architecture in SharePoint 2010 by Matt Passannante
http://vspug.com/matt/2010/02/23/planning-for-the-new-service-application-architecture-in-sharepoint-2010/

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

SQL Server Analysis Services installation went smoothly. When I reached Installation Type I again chose “Add features to an existing instance” as I wanted to add AS to the Default instance:

Feature Installation section came next and I checked Analysis Services. The Server Configuration section followed, and I remembered to take a screenshot of the Collation tab, which shows the default:

The red x on the Service Accounts tab is because I had not yet selected an account, so intent was I on taking a screenshot of the Collation tab. Back on the Services Account tab, I added the sqlsaservice account I had created for the SQL AS service. (I again encountered the “invalid data” error that forced me to re-select the account from the drop-down box during the DB Engine and RS installations.)

Next up was Analysis Services Configuration and I added myself as administrator on the Account Provisioning tab:

I left the defaults for the Data Directories, which are subdirectories in the same parent location as the DB Engine and RS directories. As I noted in the DB Engine installation article, the recommendation is to locate the data directory, log directory, and tempdb each on separate disks (for example, logical disk of a RAID array) and that none of those disks also house the OS. (Hope I got that right.) Of course, real-world, not every company has the budget for that; we all do what we best can.

Breezing through Error Reporting and the Installation Configuration Rules check, it was time to review my choices and correct any mistakes before proceeding with the actual installation, which then completed successfully.

A check for services showed all services present and accounted for:

Two errors showed up in the Application Event Log but have not repeated.

For the second error, below, I found a forum post which suggested making sure the Analysis Services OLAP local group (SQLServerMSASUser$…) has Full Control on the Cryptkey.bin file, and it does.

Interestingly, I found a KB article, http://support.microsoft.com/kb/2001727, which references these exact errors plus the “Failed to compile” DataDesigners.dll and DataProject.dll errors I reported with the SQL DB Engine installation. I did not have the other issues described in the KB article or the cause, a mismatch between user and system locales, and all services are running.

With all SQL Server features installed, here is what is added to the Start Menu in All Programs:

This concludes the SQL Server features installation. Additional configuration comes later, as part of setting up SharePoint 2010. I’ll begin SharePoint 2010 setup in the next article.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

The Installation Process

The process for installing SQL Reporting Services (RS) is the same as the DB Engine, starting from the Installation section of the SQL Server Installation Center.

The first part of the setup process, the setup files rules check, setup files installation, and setup support rules check, breezed through those with no errors.  Next up was Installation Type.  As I wanted to install RS into the same instance as the DB Engine, I selected “Add features to an existing instance of SQL Server 2008 R2”. The Default Instance MSSQLSERVER, which I had selected for the DB Engine, was preselected. If other instances of SQL Server were running on this machine the drop down arrow would present them as possible selections too.

Under Feature Selection, next, I checked Reporting Services. Note that the DB Engine and Shared Features are shown checked and greyed out (not selectable), having previously been installed for this instance. The Shared Feature directories are also not configurable.

The installation rules check and check for adequate disk space passed with no issues. It was then time to select the service account to be used for the RS service. I created a separate account named sqlrservice for this purpose. I had the same validation error as during the DB Engine installation and had to reselect the account from the drop down box before I was allowed to continue.

Up next, the Reporting Services Configuration screen provided three options: Native Mode Configuration, SharePoint Integrated Mode default configuration, and Install but do not configure the report server. The first two options were greyed out (not selectable) because I was installing RS after having already installed the DB Engine. If RS is not installed at the same time as the DB Engine only the third option is available. I did not know this and as I wanted the second option I was perplexed – what did I do wrong, oh no! Thankfully, a search on [what I thought was an issue] brought me to the explanation in the BOL. Who would have thunk?

The Error Reporting and Installation Configuration Rules check followed. The rules check completed with no errors. Finally, a chance to review the selections made, correct any errors if necessary, and finish the installation, which then completed successfully:

I did get this warning in the Application Log:

I had in the past come across the same warning for a different WMI Provider. I can’t recall which application but the solution was to leave as is. WMI by design produces a warning when a WMI provider runs under the Local System account, as described here at EventID.net, which I must mention is a great source for information and real world experience about Event Log events. KB 891642 provides more insight into the WMI Provider subsystem. I could not find any documentation instructing me to change the account for the ReportingServicesWMIProvider, therefore I left as is.

Report Server Configuration Manager

I now needed to configure RS for SharePoint Integrated Mode. The gist of the entire process is to configure RS for SharePoint integration in the RS Configuration Manager, install the RS Add-in on the SharePoint 2010 server, and complete the SharePoint 2010 configuration via Central Administration. I still have some reading on the finer points of the SharePoint 2010 side to do.

RS Configuration Manager is found in the Programs Menu under SQL 2008 R2 November CTP, Configuration Tools folder:

When launched, it provides a “Connect to a report server instance” dialog box:

Logically, as I only have one instance, that was the instance I wanted. I then proceeded down the left-side menu in order:

1. Under Service Account, “Use another account” was selected and the Account and Password boxes were prepopulated with the service account information I had specified during RS installation:


2. For Web Service URL the defaults were what I wanted. I am not using SSL. I clicked Apply. I then remembered that I had seen a video that showed the Web Service URL being configured after the database was created. So I created the database, went back to this screen and clicked Apply again. Just in case. Sometimes in IT stuff the order matters and sometimes it doesn’t and sometimes the documentation will say so and sometimes it won’t. Sometimes we get in trouble, sometimes we get in trouble no matter in which order we do it, and sometimes we don’t.


3. Under Database, the settings were blank as I had not yet created a database. I selected Change database. A Change Database wizard launched. I selected Create a new report server database:



Next, I chose to connect to the database server using my credentials (as the current logged in user):




Next, I selected SharePoint Integrated Mode and decided on SharePointRS for the database name:




Lastly, I accepted sqlrservice as the account credentials to be used to connect to the Report Server database:




That completed the wizard and the database was created. The main page then displayed the Current Report Server Database and Database Credential as I had configured via the wizard:



4. Email setup is next but I was not ready to configure that yet, so I skipped over it.


5. I also skipped over the Execution Account setting, assuming that if I need to configure this for RS integration in SharePoint 2010 the information will be noted in the corresponding SQL and SharePoint 2010 documentation, and I can do so at that time:


6. I backed up the encryption key. No way was I skipping this:


7. There will be only this one Report Server deployed, so the Scale-out Deployment setting was not applicable:

This completed the RS configuration for now. A quick check showed the RS service was running. But there were two errors in the Application Event Log post-RS configuration. The first:

I made a copy of the RSReportServer.config file to investigate with and found that the UrlRoot value is empty. The default value is http: //servername/ReportServer and that is what I configured. I have not yet read the finer details for configuring SharePoint 2010 with RS so I left as is for now.

The second error was “Failed to compile” dtsinstall.exe. A delayed error from DB Engine installation; likely, the compilation process was still occurring in the background during the RS installation. Add that to the list of “Can’t find solution”. However, I did find that DTS (Data Transformation Services) is deprecated and replaced by SQL Server Integration Services (SSIS). SQL Server 2008 setup does not install support for DTS (See Data Transformation Services (DTS) in BOL) but provides optional 32bit support (See Support for Data Transformation Services (DTS) in SQL Server 2008 in BOL).

The next article will walk through the SQL Server Analysis Services installation.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

With the SQL Server Database Engine installed, I needed to open the necessary ports in the Windows Firewall and enable the TCPIP protocol in SQL Server in order to permit network communication to SQL Server.

Opening Ports

This can be done before or after installation, through the Windows Firewall UI (User Interface, also referred to as GUI or Graphical User Interface) or command prompt. I found a comprehensive script posted by various folks who referred to this Microsoft KB: http://support.microsoft.com/kb/968872/en-us. The commands completed successfully, albeit with a message that the “netsh firewall” syntax is deprecated in Windows Server 2008 R2, the new command being “netsh advfirewall firewall”. The command reference can be found on TechNet here: Netsh AdvFirewall Firewall Commands. Netsh stands for “Network Shell”.

To practice my command line skills, I adjusted the script to use the new command syntax. The only command in the original script I could not figure out is “allow multicast broadcast response on UDP”.

--- To enable SQL Server default instance Port 1433 ---
netsh advfirewall firewall add rule name=”SQL Server” dir=in action=allow protocol=TCP localport=1433
--- To enable Dedicate SQL Administration Connection Port 1434 ---
netsh advfirewall firewall add rule name="SQL Admin Connection" dir=in action=allow protocol=TCP localport=1434 profile=domain
--- To enable SQL Service Broker Port 4022 ---
netsh advfirewall firewall add rule name="SQL Service Broker" dir=in action=allow protocol=TCP localport=4022 profile=domain
--- To enable Transact-SQL Debugger/RPC Port 135 ---
netsh advfirewall firewall add rule name="SQL Debugger/RPC" dir=in action=allow protocol=TCP localport=135 profile=domain
-- To enable SQL Analysis Services Port 2383 ---
netsh advfirewall firewall add rule name="SQL Analysis Services" dir=in action=allow protocol=TCP localport=2383 profile=domain
-- To enable SQL Browser TCP Port 2382 ---
netsh advfirewall firewall add rule name="SQL Browser TCP" dir=in action=allow protocol=TCP localport=2382 profile=domain
-- To enable SQL Browser UDP Port 1434 ---
netsh advfirewall firewall add rule name="SQL Browser UDP" dir=in action=allow protocol=UDP localport=1434 profile=domain
-- To enable HTTP Port 80 ---
netsh advfirewall firewall add rule name="HTTP" dir=in action=allow protocol=TCP localport=80 profile=domain
-- To enable SSL Port 443 ---
Netsh advfirewall firewall add rule name="SSL" dir=in action=allow protocol=TCP localport=443 profile=domain

Speaking of the command line, funny how everything old is new again. My IT career started with MS-DOS 5.0 thus the command prompt was all I had to work with. I certainly appreciated the Windows 3.1 GUI. Now we’re back to the future, and PowerShell is all the rage. Oh well, at least it’s not Edlin. I only had to learn a bit of Edlin retroactively but that was enough to scare me. So bring on Powershell; piece of cake.

Here is the Windows Firewall UI showing the ports added to the Inbound Rules: (HTTP is not shown)

Cont’d across:

Enabling Protocols

The TCPIP protocol needed to be enabled in SQL Server under both “SQL Native Client” (32bit and 64bit) and “SQL Server Network” configuration. This is done through the SQL Server Configuration Manager. (The SQL BOL is a good place to start for information on the SQL Server Configuration Manager and connecting to the SQL Server Database Engine.)

I also enabled Named Pipes. I don’t believe Named Pipes is necessary for SharePoint 2010 but it may be required for other applications using the SQL Server for back-end databases. For a brief description about each protocol shown, see Choosing a Network Protocol in the SQL BOL.

If TCPIP is not enabled, the SharePoint 2010 Setup Configuration Wizard (PSConfig UI) will throw an error when it tries to contact the SQL Server to create the SharePoint_config database:

This is what happened to us at work. We missed enabling TCPIP under the SQL Server Network Configuration setting. We did not realize we missed enabling TCPIP under the Server setting, so we spent about half an hour looking for other reasons until we finally did an Internet search on the error. Some others have run into this error and the suggested solutions indicated communication issues. Eliminating the network and firewall settings as the cause led us to the SQL network configuration settings.

That is all I needed to do for the test network. The next article will walk through installing SQL Server Reporting Services and configuring the RS instance for SharePoint Integrated Mode.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

You cannot have SharePoint without SQL Server in one edition or another.

I decided to install SQL Server 2008 R2 Enterprise CTP in three steps: the Database Engine (DB Engine) and Shared Features first, followed by Reporting Services (RS) and finally Analysis Services (AS). The Shared Features include the Management Tools.

Analysis Services can be installed in “traditional” mode and beginning with SQL Server 2008 R2, in “AS with SharePoint integration” mode; the latter mode is PowerPivot. SQL Server Enterprise edition is required for PowerPivot. The PowerPivot team has a blog post: Comparing Analysis Services and PowerPivot. We need traditional AS and our Finance department will be interested in PowerPivot, so we will be installing both. We will install PowerPivot last, after installing and configuring SharePoint 2010 and Project Server 2010.

Reporting Services also has two modes: traditional RS and “RS in SharePoint-integrated mode”. We will be using RS with SharePoint exclusively, so the latter mode is all we will configure.

DB Engine Installation

The DB Engine/Shared Features installation was easy. Starting setup launched the SQL Server Installation Center, which is sectionalized based on function and provides information, documentation, and guidance in one place: [All screenshots are from my home network installation.]

Speaking generally, setup routines have come a long way from Windows 3.1. The routines tell you what they are doing and indicate when a step will take a long time, so you don’t think the installation has frozen and you forcibly stop it which [used to] lead to all sorts of trouble. The routines have Back buttons to allow you to correct mistakes, Retry buttons if you mistype and cause an error, and “Fix the issue and try again” if you encounter an error midstream. They also roll back changes if you cancel during the installation process. Who would have ever imagined? (Alas, some companies still do not provide decent setup routines.)

When SQL setup runs it first checks to see if the prerequisites are installed. See Hardware and Software Requirements in the SQL 2008 R2 BOL (Books Online), the primary documentation for SQL. (BOL installs with SQL, can be accessed online at TechNet or MSDN, and can also be downloaded from the Microsoft Download Center.) Once the prerequisites are installed the SQL Server installation routine starts.

1. The Installation section presents five options. I needed the first option: New installation or add features to an existing installation:




Note the use of the term “instance” in the option description. For those of you unfamiliar with SQL Server, an instance is a copy of SQL Server running on a computer. More than one copy can be installed onto the same computer. The multiple instances run concurrently but are separate. For example, each instance of the DB Engine has its own system databases. You can have multiple instances of AS and/or RS in addition to multiple instances of the DB Engine. The number of allowed instances is based on SQL edition licensing. Each instance except for a “Default instance” requires a unique name and is referred to as a “Named instance”. Typically the Default instance is used for the first instance each of the DB Engine, AS, and RS, but you can use a Named instance instead.  The choice is offered during installation as long as the Default instance has not already been used. The SQL Server Reference Guide at InformIT.com is one resource that provides a detailed explanation.

The “Please wait” message, which appears several times during installation, popped up:




2. Setup checks for requisites before installing the Setup Support files. If a problem is found setup provides information about it. No issues were found.






3. Product key time or select free 180-day evaluation:



4. License terms are presented next. (No screenshot but of course if you want to continue you have to agree.)
5. Ready to install Setup Support Files:



6. Once the Setup Support Files are installed the real action begins. Setup runs another check. Note the Windows Firewall warning; this happens every time setup is run. It is simply a warning to make sure the ports necessary for network communication are open. I did so after installation.




The Warning link provided this message:




7. Role Selection is next, with three options for which features to install and how. The second option “Analysis Services with SharePoint Integration” is PowerPivot (Gemini was the code name). The first and third options provide all other features except PowerPivot. The first option allows you to selectively control which features to install, whereas the third option installs all of the same items at once using default values. As I wanted to control which features to install I chose the first option:




Note that PowerPivot is only available via the second option, as PowerPivot requires its own named instance (the name is hardcoded). There can be only one PowerPivot instance per server, though you can install other (traditional mode) AS instances on the server, and you can install PowerPivot on multiple servers to scale it out. (Yes, confusing. I finally got the hang of it after a while.) Too, PowerPivot installs onto a SharePoint application server. In a one-server scenario this is the same machine as SQL, though the one-server scenario is typically for testing and development.

8. Feature Selection follows. I chose all features, except of course AS and RS so that I could install each separately afterwards. Note: If you want to install the AdventureWorks2008R2 sample databases (SQL Server 2008 R2 November CTP AdventureWorks Sample Databases), Full-text Search must be installed.



Note that Books Online is always installed; the selection is checked and cannot be unchecked.

9. Setup checks for any potential problems that might interfere with installation:



All of the rules marked “Not Applicable” appear to apply to PowerPivot or RS in SharePoint Integrated mode, except for the 64-bit processor and operating system rules. I can only imagine the latter two are marked “Not applicable” because SQL Server 2008 R2 is 64-bit only and setup would have balked from the start on a 32-bit machine with a 32-bit OS.

10. Next up is Instance Configuration. Here is the spot to select the Default instance or create a Named instance. SharePoint can use either; in fact a Named instance is necessary if the Default instance is being used by another web application. I chose the Default instance. The port defaults to 1433 and the name to MSSQLSERVER. Here is also where to specify the location for the Instance root directory.


11. Setup checks for available disk space:


12. The Server Configuration stage is next and presents two tabs: “Service Accounts” and “Collation”. On the Service Accounts tab I selected the service account I created for the DB Engine. I am using the same account for the SQL Server Agent as well. (See About SQL Server Agent in the BOL for an explanation of what the Agent does.)



Quirk report: When I clicked Next (totally forgetting about the Collation tab, by the way), setup threw an error:




Thinking I had typed the password wrong, I retyped it. Same error. I cleared account and password from all cells and then manually typed them in. Same error. And again. (You would think that I would think I got it right by then, and I did think that. How slowly can you type a password and get it wrong?) So I changed the password in Active Directory, waited for replication to the other DC, and tried again. Same error.  So I thought and thought. (In my defense, it was after midnight.) If the password was not the issue, the account must be. Process of elimination time. I had browsed for the account in the Agent cell. I had selected it from the drop down in the DB Engine cell. I had manually typed it in both cells. The only thing I did not try was to select the account from the drop down in the Agent cell. And voila! No error.




Well, after that exhausting brain exercise, I forgot about the Collation tab. I wanted the default anyway, and as for the screenshot, there’s more than one way to get the job done:




Note: Microsoft recently issued a “Fast Publish” KB article Supportability regarding SQL collation for SharePoint Databases and TempDB that stresses the default collation is required for SharePoint databases and tempdb, which is one of SQL Server’s system databases. (For an overview of the system databases see this two-page article at SQL-Server-Performance.com. See Understanding Databases in the SQL Server 2008 R2 BOL for in-depth material.) SharePoint 2010 is not listed in the applicable products section of the KB (WSS and MOSS are) and I cannot find mention of same for SharePoint 2010 on TechNet (did I miss it?), but I have no reason to change the default.

13. The Database Engine Configuration section, next, has three tabs: Account Provisioning, Data Directories, and FILESTREAM. On the Account Provisioning tab, I selected the Authentication Mode and specified the SQL DB Admins:



The Data Directories tab provides granular control for file locations. The MS SQL Server team recommends the database files (.mdf), database log files (.ldf), and tempdb be placed on separate disks (not just separate partitions) and none be placed on the OS disk. For the test network we mimicked with partitions. (This screenshot shows my home network; everything got plopped on C:\)




The FILESTREAM tab: Perhaps I’ll experiment with this, so I enabled the solution and provided a share name for SharePoint 2010 to use:




Here’s a “somewhat” explanation of FILESTREAM: FILESTREAM is a solution to help manage unstructured data. SharePoint content is either structured or unstructured. Unstructured data includes, for example, documents, images, and videos. Up until SQL Server 2008, when FILESTREAM was introduced, all data lived in SharePoint databases. Unstructured data is stored in a database as a BLOB (Binary Large Object). (The term never fails to conjure up the movie. The Steve McQueen version.) FILESTREAM provides the ability to store unstructured data in the NT file system instead of the database. SharePoint takes care of keeping track of the data, and with 2010 SharePoint fully supports remote BLOB storage (RBS). If I recall correctly, one of the SharePoint 2010 conference sessions cited 5 terabytes (5TB) as the price/performance point at which RBS could be considered. 

14. Error Reporting is the next step:


15. Another Rules check:


16. Finally, we are ready to review the choices and install. This is the time and place to inspect the chosen settings carefully and use the Back button to correct any mistakes.



17. Installation completed successfully:

A post-installation check showed the SQL services were present and the SQL service was running. I started SQL Server Agent and changed its startup type to Automatic. I connected to the DB Engine using SQL Server Management Studio and the System Databases (except for the read-only, hidden Resource Database), Security Logins and Server Roles were present:

There were quite a number of errors in a row in the Application Event Log regarding Visual Studio Templates, such as:

The last error summarized the issue:

A search revealed the referenced Visual Studio applications (C# in the above case) were not installed. SQL Server does not install these VS applications so I ignored the errors.

There were also two Event ID 1101 .NET Runtime Optimization errors: “Failed to compile” DataDesigners.dll and DataProjects.dll, respectively. I found out these files are part of the Microsoft Visual Database Tools (VTD) Package 8.00 and the error means that native images for the files were not generated and installed.  A search turned up a few others had the errors on installation but I did not see a solution. One forum poster tried using the ngen utility (MSDN link) to generate and install the native images but that did not work. (I did not try – I did learn a tiny bit about ngen and how to display a list of native images but I need to understand more first.) Hopefully there will be more information if we run into these errors at RTM. I don’t believe these will impact the Beta testing.

I still needed to open the necessary ports in the Windows Firewall and enable the necessary protocols in SQL Server Configuration Manager. I will walk through these steps in my next article.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.

Guest Author: Joan Resnick Ehrlich

Hardware

The first step was to procure new hardware for our test network, which consists of six aged 32-bit desktops I scrounged up and added RAM to. As all of the new and upcoming releases are 64-bit only, the current setup ain’t gonna work. Having an actual budget this time for a test network, we wanted to mimic our planned software structure as much as possible within the budget, even if we could not mimic the hardware. SharePoint 2010 is part of a larger plan to update our back end server infrastructure and include Hyper-V virtualization.

Virtualization, which is a technology, is rather amazing. There are a number of types of virtualization. See Wikipedia or TechTarget’s SearchVirtualization.com site for an explanation. [Note: TechTarget requires membership signup but the membership is free and gains you access to all TechTarget websites.] See Microsoft for information on Hyper-V, which provides machine virtualization. Here’s a “somewhat” explanation of machine virtualization, as I am new to this too: It allows you to create “virtual hard drives” (VHDs) out of disk space on an actual hard drive. It requires a virtualization capable processor and a virtualization capable OS or application. After you create a VHD you can install an OS in it as if the VHD was a separate machine, but it’s really a file with accompanying configuration files; a “virtual machine” (VM). You can have multiple VMs on one physical machine, up to what the licensing for the virtualization product permits. This means that you can cut down on the number of physical machines you need for servers. The machine containing the VMs is known as the “host” and the VMs are the “guests”. As I said, rather amazing.

Anyway, we were able to wrangle four mid-tier “rack servers” out of the allotted budget. (A rack server lays flat and slides into a rack unit like shelves into an oven.)  The following describes the hardware and operating system setup, so feel free to skip or leave a comment for clarification if you are not familiar with a term or your eyes glaze over, or if your appreciation for IT increases. As we are working with virtualized servers as well as physical servers, and server really refers to the role a machine plays, I’ll try to use the word machine when referring to the actual physical hardware.

Two machines were ordered with 8GB RAM (memory chips) and the other two with 12GB RAM. Otherwise, the hardware is identical. Each machine has three hard drives in a RAID 5 array plus a hot spare. RAID = “Redundant Array of Independent Disks” or if you’ve been around a while like me, “Redundant Array of Inexpensive Disks”. There are different types of RAID.  See Wikipedia or TechTarget’s SearchStorage.com site or just search on RAID. Here’s a “somewhat” explanation of RAID 5: Three or more disks are configured to look and act as one drive, the data is written across all disks, and there’s redundancy built in to prevent data loss if a disk fails. If you have one or more hot spares configured (like a spare tire waiting to be used), and a disk(s) fails, the server grabs the hot spare(s) and replaces the failed disk(s). (Ok, a car can’t do that. But if a car can park itself, is that far behind?)

We received two machines (one of each RAM configuration) and decided to proceed while we await the remaining two, which we ordered at a later date. We designated the 8GB RAM machine for SQL Server as we have decided not to virtualize SQL.  We designated the 12GB RAM as a Hyper-V host. The two machines to be delivered will be configured as a DC (so we have one DC that is not virtualized) and another Hyper-V host.

OS (Operating System)

We installed and configured Windows Server 2008 R2 on both machines. We then added the Hyper-V role to the 12GB RAM machine, configured three guest VMs, and installed and configured Windows Server 2008 R2 as the guests’ OS. We joined all servers to the existing test network domain and set up a DC in one of the guests so that we have a Windows 2008 R2 DC. We retired one of the Windows Server 2003 DCs (and that hard drive died immediately after, no joke), transferring its DC roles (Schema Master, PDC Emulator) to the new DC and reconfiguring DNS settings in the process. We are keeping the second Windows Server 2003 DC temporarily until we receive the other two new machines. (Never have just one DC.)

At Home

On my home test network, I have four identical 2-year old low-end servers (no budget, scrape, scrape). These replaced three circa 2000 Pentium II and III desktops that were still cranking away but it was time for 64-bit. Unfortunately, the processor chip cannot do virtualization, who knew?  Two are now Windows Server 2008 R2 DCs and the third houses Exchange Server 2010 Enterprise. I repurposed the fourth for SQL Server and SharePoint. Thus, I will have a one-server farm with SQL on the same machine.

Whew! That all went smoothly. Now I was ready to set up the service accounts for SQL Server and SharePoint.

Creating the Services Accounts

We are following the advice to have separate web application pools for each service application, and separate managed service accounts for each application pool, even with the Beta. Here’s a “somewhat” explanation of an application pool, but don’t go by me: An application pool provides a way of setting a boundary between service applications. When each service application runs in its own application pool, its processes are isolated and won’t affect the other service applications’ processes.

Accordingly, I created domain user accounts on our test network for the managed service accounts. All names are very original, I’m sure. I followed Microsoft’s directions for “least privileged” accounts – don’t grant permissions or access to anything more than what is required. I forgot several, but no worries; I created them when setting up the corresponding service application. Here’s the list:

That’s it for now. In the next article I will step through the SQL Server 2008 R2 Enterprise Database Engine installation and configuration.

Post note: The two servers we were waiting for arrived today, yes!

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.