Friday, June 04, 2010

SharePoint 2010 RTM - Least Privilege Install - My Experience

  • WARNING [11/11/2010]: It looks like Google's update to the template and rich text editor has mangled my post, so watch out for instructions that don't make sense or are out of order.... I need to replace this whole article now

  • Update [5/10/2010]: I've actually switched to a script based install, which appears to get around some of the problems that I'm seeing (I think User Profile Syncing is working, nearly!), but there's still a lot of manual UI config to be done and some service applications can't have their DB specified in PowerShell.  Look for a new article detailing this soon!
  • Update [5/10/2010]: Added new bullet point for enabling the Diagnotstic Data Provider: Performance Counters - Database Servers timer job to connect to the SQL server when using SQL Aliases.
  • Update [9/07/2010]: Added new bullet point for enabling the Managed Metadata feature for sites.
  • Update [30/06/2010]: Added new bullet point for Developer (Visual Studio 2010) access.
  • Update [16/06/2010]: Added fix for browser language/locale issue in phonetic search. Applies to SharePoint Search and FAST.



Preamble:



OK, so we've been using SharePoint 2007 here at work since it came out (actually we started while it was still in Beta) and we've been somewhat gagging at the bit for SharePoint 2010 and the promises it's made. Some we've seen ourselves, as I installed first the Beta2 and then the RC, with somewhat mixed results. (Basically next, next, next, finish installs, as that's all the advice that was available at the time.)



Now things have changed a little, the RTM is out and next, next, next just doesn't cut it. It's fine for quickly throwing up a primitive VM, but when you're trying to learn the product and install in a manor that will actually teach you what's going to happen when you try to install into your Production environment, then it's the hard way, all the way.



What follows is the guts of my install process, some of the gotcha's I hit along the way and how I resolved them. It also skips various bits, some because I'm not going to tell you how to press Next and others because I just haven't installed those parts, yet.



It's by no means perfect, I have a small cluster of errors turning up in my logs, some I know what they're from but haven't found a solution, others are completely unknown.



So please use the comments to send me feedback, particularly on what I've completely munged...



Oh and you wont find a boat load of screenshots or lists of commands. If you need screenshots to install something, either it's too complex, or you shouldn't be installing it... :) And long lists of commands don't really offer anything useful other than polluting search results...



Eventually I'll extend this with bits on FAST (which I think I've managed to install with virtually no pain) and playing with the BCS (as this is going to be important for us in the future).



So here goes...



  1. Pre-installs
    OK, I'm assuming you've got something like Windows Server 2008R2 x64 based VMs. I ended up with three:
    • SPS01 - 1 CPU, 4Gig RAM, 40Gig C:
    • SQL01 - 1 CPU, 4Gig RAM, 40Gig C: (sys), 30Gig E: (data), 20Gig F: (logs)
    • FAST01 - 2 CPU, 4Gig RAM, 50Gig C:


      Install something like SQL2008R2 x64 on the SQL box and configure it up (engine, AS, RS, Agent & FullText).
      Install the SQL2008R2 x64 client on the SharePoint and Fast boxes.
       Bonus SQL step:
      On the SQL server, give the Local SQLServerMSSQLUser... group, Local Launch permission on MsDtsServer100 in Component Services (DCOM) to allow error free overnight maintenance scripts.
  2. Extra Bonus SQL step:
    If you use SQL Aliases (and currently I can't see the point, despite it being "best practice", DNS aliases/CNAMEs seem to make far more sense), ensure you have a DNS alias/CNAME that does the same mapping, to allow the Diagnostic Data Provider: Performance Counters - Database Servers timer job to establish an RPC connection to the SQL server.



    Microsoft have a couple of other pointers HERE
  3. Follow THESE instructions to set up a SharePoint AD Container (optional, it's for tracking SP2010 installs on your Domain/Forrest)
  4. Do a full install from the SP2010 media, we're licenced for Enterprise edition and this is the only time I did pretty much a "full" (Server Farm/Complete) next, next... type install. Use somthing like THESE instructions to guide you.
    I installed using my personal Admin level account (domain admin), a SQLService account (used to run the SQL processes on the SQL box, standard SQL type stuff) and a Farm Account/SQL Access account, which at this point is my "Swiss Army" account, as if you stop using it, things start to break... The Farm Account had special privs in SQL and is a local admin on the SharePoint box. The latter is only for the duration of the install/setup (you'll see why later when you hit the User Profile Service) and isn't mentioned in those instructions.
  5. Run the SharePoint Products Configuration Wizard (or just let it run at the end of the install)
  6. OK, now this is where Next, Next, Next... stops. Feel free to join the User Experience Program (it's up to you), but I'm trying not to use the Farm Configuration Wizard...
  7. Now is a good time to open up some ports on the Windows Firewall on your SP box, as your Central Admin port is unlikely to be available other than locally (you might as well ensure any other ports you intend to use are open too)
  8. Now is a good time to set up some more DCOM permissions (reminds me of SP2007....)
    • The Farm Account will need Local Activation permissions on both IIS WAMREG and 000C101C-0000-0000-C000-000000000046 (MSIServer)
      Remember, that's back in Component Services DCOM
  9. Now I set up a beginning set of Service Applications.
    I've recently seen suggestions that the "Services on Server" services should be started before the Service Applications are created/configured, but I saw this afterwards...

    First up is the Secure Store Service:
  10. Next up is the Usage and Health Collection Service Application
    • open an Administrative SharePoint PowerShell and execute something like:

      New-SPUsageApplication -Name "[servicename]" -DatabaseName [usagedbname] -DatabaseServer [dbserveralias]

      This creates the service and it's proxy, but for me it leaves the proxy stopped and I haven't investigated far enough to figure out why.
  11. Next up is the State Service Application
    • in the PowerShell you left open from step 10 (you didn't close it right?) execute something like the following:

      New-SPStateServiceDatabase -Name [statedbname]-DatabaseServer [dbserveralias]

      New-SPStateServiceApplication -Name "[servicename]" -Database [samestatedbname]

      New-SPStateServiceApplicationProxy -ServiceApplication "[sameservicename]" -Name "[sameservicename] Proxy" -DefaultProxyGroup


      This creates the State Service DB, assigns it to a new State Service and then assigns the State Service to a new State Service Proxy.
  12. Next up is the Session State Service
    • again in your PowerShell console:

      Enable-SPSessionStateService -DatabaseName [sessiondbname] -DatabaseServer [dbserveralias]
      This creates the Session DB and assigns it to a new Session State Service Application, which is automatically called "SharePoint Server ASP.NET Session State Service"
  13. Now for the Web Analytics Service Application
  14. Time for the Managed Metadata Service
    Note: my MMS seems to have a bit of a bumpy life, often reporting as not available, but we've been having disk issues in our SAN which _might_ be the cause.
  15. Time for the Search Service Application:
  16. Might as well configure up the SharePoint Foundation Help Search Service:
  17. About now the SP server event logs will start complaining about no Cache Super User account for the Central admin, so run:
    stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue [lowprivdomainaccount] -url [urlofsite]
  18. Fix the TaxonomyPicker Control issue:
  19. Start the Application Registry Service and Claims to Windows Token Service:
  20. Start the Microsoft SharePoint Foundation Subscription Settings Service and the Microsoft SharePoint Foundation Sandboxed Code Service
  21. At about this point I create my two primary Web Apps:
  22. Create local profiles for App Pool accounts:
    • IIS7/Win2008R2 seems to like App Pool accounts to have local profiles (otherwise it assigns a temp one each time an App Pool starts), so you can create one using the instructions HERE
  23. The Site Directory feature is turned off in SP2010 by default (to avoid migration/upgrade conflicts). I'm not attempting to migrate right now, so I've turned it on using THESE instructions.
    • Make sure the Publishing Feature is turned on at the Site Collection level and probably about time to check that the Standard SharePoint Features are turned on too
  24. OK, here's where the real fun begins (or at least the most issues...), yes, it's time to set up the User Profile Service:Configure and start the Document Conversion Load Balancer service on a memorable port (I've pretty much used a sequential set of ports for services I have control over)
    • Ensure MSIServer has Local Activation for Network Service in Component Services (may need to assume ownership and add full control to regkey HKCR/AppID/...)
    • Ensure MSDTC has network incoming permissions (in Component Services)
    • Follow the instructions HERE as they are awesome and work!
    • If your NETBIOS AD Domain name is different from your FQDN, then use that bit of the instructions HERE. Here at CT we need to do this.
    • I'm still getting what look like UPS related errors:
      • Product: Microsoft User Profiles -- Error 1706. An installation package for the product Microsoft User Profiles cannot be found. Try the installation again using a valid copy of the installation package 'pplwfe.msi'.
        My attempt to fix this consists of finding pplwfe.msi on the SharePoint2010 install media and running it manually. Now I have to wait and see if that has fixed it.
        Note: After a reboot I started getting a "trial expired" error on all Web Apps except the Central Admin so had to re-run the Products Configuration Wizard.
      • Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM' failed during request for component '{1681AE41-ADA8-4B70-BC11-98A5A4EDD046}'and
        Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM', component '{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}' failed. The resource 'C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe' does not exist.
        I'm guessing that these two are related. So far, general concensus on the net is that a "proper" install of UPS makes these go away. However, aside from using the Wizard, I've not managed to make them go away...
  25. Configure and start the Document Conversion Launcher Service, point it at the Load Balancer in step 25.
  26. At this point the Health Analyzer will be screaming at you to stop using Local Service accounts and to stop using the Farm Account.
    I still need to work my way through these, ensuring that things don't break when I change the account. I think I'll use a single domain based "Services" account to run most of it, which has no privs, other than what SharePoint assigns it.
  27. Enable the BlobCache as per MS's Instructions for each WebApp (aside: looks like MS have rearchitected the BLOBCache for 2010)
  28. Now for some Optional Bits:
    Install FAST:
    • We're licensed to use FAST and quite keen to extend it into some of our LOB systems.
    • THESE instructions from MS are quite good (and don't forget to install WebApps on the SP server first!)
    • But expect to hit THIS problem, so use a completely unheard of account format ([domainfqdn]\[fastserviceaccount], e.g. microsoft.com\FASTAccount) Note: you'll also hit this issue when configuring the Click-Through-Relevancy settings.

    I'm currently seeing one FAST related error:
    • On the SharePoint side from Schannel [36888] Error: Error: The following fatal alert was generated: 10. The internal error state is 10.
    • On the FAST side from Schannel [36885] Warning: When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.

    Though this seems minor and unaviodable in this day and age (number of Root CAs installed on Windows by default)
  29. Set up PDF indexing for normal SharePoint Search (if you're not using FAST, or in my case, I'm using both, for direct comparison) using THESE instructions
  30. If you want to add Managed Metadata Columns to your sites, don't forget to MANUALLY enable the feature:

    STSADM -o activatefeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C -url http://<server> -force
  31. Developer Access:

    Visual Studio 2010 users will need to:
    1. Run VS2010 as Administrator and
    2. have dbo level access to the Web App Content DBs
    3. have dbo level access to the Farm Config DB
    • Main Content (don't forget to do the Cache Super User account thing as per step 17)
      • Generally I create blank publishing site collection for the root
    • MySites (as with Main Content, do the Cache Super User thing)
      • I'm currently using a separate port (http://sphost:81/) to pick out my MySites, as this is where we ended up with SP2007. Before going production, I'd like to change this to use host headers and a separate DNS name.
      • Don't forget to create a "My Sites Host" site collection
    • In the past I've used separate App Pools for my Main Content and MySite Web Apps, but general advice out there at the moment seem to be to use the same one. I suspect I'll keep them separate in production.
    • Yes, I'm using a low priv Domain Account for the App Pool
    • I suspect I need to use the wizard (or a command line) to create the Application Registry Service correctly, but haven't gone down that path yet
    • May hit THIS or THIS issue
    • Don't change the service account (for Claims to Windows Token Service) from Local System, as this will cause more problems. However this means that the Health Reports will reporting a local system account in use... [false positive]
    • According to THIS website you need to fix an HTML/XML encoding error in the file
    • Note: replace & #44; not &#44 (remember the semicolon)
    • I found this didn't wrok (error still turns up after App Pool recycle or IISRESET), so ending up renaming the TaxonomyPicker.ascx file as apparently it's not used anymore.
    • Note: running PSConfig seems to re-create this file...
    • Pretty much default config. I'm currently using the Farm Account for the App Pool and a low priv account for crawling/content access.
    • Start the service once you've configured it.
    • Ensure the crawling account has permission to crawl MySites as per THIS article
    • Note: We hit THIS problem, which is where the SharePoint Core Search Results (and same for FAST) don't recognise the en-NZ locale from the browser (yes, we're in New Zealand, yes we speak English), as opposed to en-US. So you need to go into the search results page (for SharePoint search and/or FAST search) and force the language to English. I'm guessing that the American programmers forgot that en, en-UK, en-AU, en-NZ, en-US, etc are more or less the same (ahh, though there are spelling differences of course and I bet that the English setting is en-US!). This is all well and good, but the People Matches webpart doesn't have the same language setting, so you have to go to the People scope to get phonetic/spell-checked people results... [sigh]
    • I've found that I need to give the Farm Account full control of regkey:
      HKLM\SYSTEM\CurrentControlSet\services\VSS\Diag
      to prevent some errors turning up in the Event Log.
    • you may need to navigate to the searchadministration page to ensure that some controls get registered properly, as per THIS and THIS article
    • again, use the Farm Account for the App Pool
    • and don't for get to start the Managed Metadata Web Service in the Services on Server page
    • IISRESET
    • ensure the Farm Account as sufficient permissions to the MMS as per THESE instructions, though they should only apply if you DON'T use the Farm Account... but not entirely sure...
    • it'll pay to navigate to the MMS to ensure that it's running OK, perhaps create a Term Store and some Terms while you're there...
    • Give it a nice name
    • create a new app pool based on the Farm Account
    • give the Staging and Reporting DBs nice names
    • read the dialog at the end and follow it closely:
      • to start the two Web Analytics services in "Services on Server"
      • configure and enable the usage schedules (optionally including DB performance) from the Monitoring Review job definitions page
      • add the Farm Account to the Performance Monitor Users local group on the SQL server
    • IISRESET
    • create a new Secure Store Service Application on the Central Admin Application Management Manage Service Applications page
    • time to point out that the Nav in Central Admin really bites...
    • give it a nice name and give the DB a nice name too
    • use the Farm Account for the App Pool
    • start the "Secure Store Service" on the Services on Server page.
    • Do an IISRESET in an Administrator CMD console
    • Don't forget to create a new Key from the new Secure Store Service Application on the Manage Service Applications page
    • Create a New Farm
    • Use a SQL Server Alias (became a best practice for SP2007 too late for me to impliment, so now I'm making sure I use them for Sp2010. Don't like the way it's all done with Registry Keys though...)
    • Use a good naming scheme for naming your DBs. Unless you live in PowerScript land, you won't be able to choose the names of all your DBs, but the least you can do is logically name the ones you do have control over.
    • I use a consistent port for all our Central Admins and tend to stick with NTLM for them too (we have Kerberos working with our Intranet, primarily to support SSRS)
And that's it for now. That's as far as I've gotten. My main goal at the moment is to hook FAST up to content and get that running slick. Secondary goals are to get rid of any errors turning up in the event logs and to set up the remaining services (Excel, Performance Point, PowerPoint, Access, etc)
If you use these instructions and hit any problems, please do let me know, or if you've seen any of the same problems as me, but resolved, them, please drop me a comment.
Later'ish
Craig

8 comments:

Anonymous said...

Nice article .Thanks for step by step info . You also mentioned use farm account for app pool for some service applicaions . I was wondering if we can use same app pool for all these service apps or what is the prefred way. I dont think creating app pool for each service app is good idea since its 64 bit application now .
Once again thanks

Craig Humphrey said...

Thanks for the comment.

Yeah, I'm thinking that at least some of the App Pools should be moved to another, probably generic and shared, service account.

I just need the time to step through each one, changing it's account and letting it run for a few days to see if it introduces any new issues.

This then begs the question, what would happen if you used the alternative account at install/setup time? We already see with the case of the Profile Sync, that you need a high-priv account during install/setup, which can then be demoted, but what other services will get into trouble if you use a low priv account at install/setup time?

Happy SharePointing!

Anonymous said...

Hi Craig,
Very nice article. I have one question. I used the Config Wizard to set up my environment (in hindsight, I wish I wouldn't have). The Service Application - App Pools default to "SharePoint Web Service Default". I'd like to change all these to my own App Pool. I'm using SP2010 Standard and have already run a Search Crawl. My question is are there any issues with doing so? My main concern here is having run a crawl and what effect changing the Search Service App-App Pool may have. I may leave that one as is, but change the others such as BCS, Metatdata Mgmt, etc..Thoughts?

Craig Humphrey said...

Thanks for the comment.

As long as you use the CA | Security | General Security | Configure Service Accounts to change the account for the Service/App pool you _should_ be OK.

As SharePoint should set up the appropriate DB/file permissions for you, though of course every now and then it might not... It doesn't seem to be quite as smart as say SQL Server, which is pretty good at changing it's service account.

One thing to watch, if you're moving from a service account that is a local or domain admin to a non-admin account, any files it's created will be owned by the local administrators group, which _may_ cause issues for the non-admin account.

While during my initial testing I did change the accounts used by some of my services, I've not done it on my current install, though I do need to. So I'll update this post when I've done it.

I presume you're already using a separate, low privledged account for the crawling/indexing. If you use a high priv account for this, you're likely to run into problems, as it may be able to access/edit content that would be undesireable.

Later'ish
Craig

Unknown said...

I am still getting this error as well:

Product: Microsoft User Profiles -- Error 1706. An installation package for the product Microsoft User Profiles cannot be found. Try the installation again using a valid copy of the installation package 'pplwfe.msi'.


Any luck yet on fixing this one?

Craig Humphrey said...

Hi Chris,

sorry, I haven't yet. Though I've been heavily distracted by my efforts with FAST connectors.

If you do come across a solution, please let me know and I'll update this page if I find one.

Later'ish
Craig

Gavin McKay said...

Hi RE SQL Server aliases, using a DNS entry won't allow you to change ports, communication methods, or SQL instance names. That's why they are better than DNS entries.

We had a particular case at a client site where we did not have a sql cluster available originally, so we had to allow for a move from sql01\nocluster to sqlcluster\production. Using an alias allowed this change, whereas I don't think it would have been possible with a DNS change. DNS changes would be fine for default instances though.

Craig Humphrey said...

Hi Gavin,

while I agree that a DNS alias can't specify port and instance, it doesn't usually need to.

With a DNS alias you can still specify the port (I think) and instance (definitly) in the connection string.

It's rare for me to use anything other than the default instance, or default port, these days, and given that management of SQL Aliases is non-existant and some apps don't support them (even within SharePoint/FAST!), DNS aliases just seem to make far more sense.

But that's just my 2c.

I suspect it's only a matter of time before MS lets AD/Group Policy drive SQL Aliases, at which point it would be trivial to have a matching DNS alias.