After the break, there’s a full table that lists out all of the necessary antivirus exclusions that should be configured for Windows servers that are running SharePoint 2010 and/or SQL 2008 R2:

(I’m sorry in advance for how unreadable this may be with the CSS I have right now. I don’t have time to fix it…)

References:

• Microsoft Support KB822158 – "Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows": http://support.microsoft.com/kb/822158
• Microsoft Support KB952167 – "Certain folders may have to be excluded from antivirus scanning when you use a file-level antivirus program in SharePoint": http://support.microsoft.com/kb/952167
• Microsoft Support KB309422 – "How to choose antivirus software to run on computers that are running SQL Server": http://support.microsoft.com/kb/309422

Technorati Tags: Antivirus, performance, SharePoint, SQL Server

Take for example, you install the bits for the service pack 1 upgrade. The first thing, of course, is that you need to finish installing those bits on all of the servers in your farm. But then after that you need to run the SharePoint Products Configuration Wizard (or run psconfig.exe) to upgrade the installation. I recommend running the wizard first on the app server that serves your Central Administration site. But you really need to wait until it’s finished before running the config wizard on your next server. If you do rush ahead, it won’t let you. I tried it just to see what would happen. When I started the second config wizard in the process, the screen stayed just like this until the first server was finished with the wizard.

So it looks like there is a flag that is checked before it starts. And if one server already is locking up the configuration, the next one will not start until the first is finished.

Technorati Tags: Install, psconfig, SharePoint

For those that may find it interesting, here is a list of scope-growing factors that can add major complexity to a simple SharePoint implementation:

• Incoming email functionality
• Non-AD profile sync connections
• Write-to AD functionality for profile-sync (as opposed to reading from Active Directory only)
• Forms based authentication or claims authentication (instead of old-school Windows auth)
• Search content sources other than the local SharePoint content
• FAST Search (instead of regular SharePoint search)
• PowerPivot
• Project Server
• Team Foundation Server
• SQL Reporting Services
• Migration or upgrading of content from other SharePoint farms
• Publishing service applications to other SharePoint farms
• 3rd party add-ons

Technorati Tags: consulting, SharePoint

Log Name:      Application
Source:        MsiInstaller
Date:          9/29/2011 1:10:10 PM
Event ID:      11406
Task Category: None
Level:         Error
Keywords:      Classic
User:          DOMAIN\#ServiceAccount
Computer:      localcomputername
Description:
Product: Microsoft Forefront Threat Management Gateway — Error 1406.Could not write value InstalledBy to key \SOFTWARE\Microsoft\Updates\Microsoft Forefront Threat Management Gateway\7.0.8108\Service Pack 1.  System error .  Verify that you have sufficient access to that key, or contact your support personnel.

There was nothing out there helping me. I finally found in Microsoft KB969865 saying: “When you run .NET Framework 3.5 SP1 setup with a user account whose name begins with a ‘#’ character, the installation will fail.” and then it gives the error, which is the exact same as the one I got. In the cause section, it explains that the install tries to write a registry value with the “InstalledBy” username. But the ‘#’ character just happens to be a special prefix character in registry values.

So I tried it again with a different account and the install finishes with no problems at all.

Technorati Tags: Install, TMG, UAG

But this time I had a horrible time doing it. I don’t know if these factors had anything to do with it but my situation included the following noteworthy factors:

• Brand new SQL 2008 R2 CU7 Active/Passive clustered SQL environment with a named instance
• SQL is configured to use dynamic ports only on TCP/IP
• My SharePoint 2010 hosts is configured to connect to use SQL client aliases to connect
• SharePoint 2010 was installed with media that was slipstreamed with service pack 1 and the June 2011 CU

Here is the command I was trying to use:

psconfig.exe -cmd configdb -create -server MYSQLAliasName -database FancyPrefix_SharePoint_Config -dbuser Domain\SPfarm -dbpassword SomePassword -user Domain\spadmin -password SomePassword -admincontentdatabase SP_FTIAP_Admin_Content –passphrase MY_passphrase

The error I got in command-prompt window was:

The configdb command is invalid or a failure has been encountered.
Cannot connect to database master at SQL server at MYSQLAliasName. The database might not
exist, or the current user does not have permission to connect to it.

Not helpful. After verifying that I was able to connect I turned to look at the database server. But on the SQL server there was a more descriptive error in the SQL Logs:

Error: 18456, Severity: 14, State: 6.

Message
Login failed for user ‘Domain\SPfarm’. Reason: Attempting to use an NT account name with SQL Server Authentication.

So at first, I tried to configure SQL to accept Windows Authentication only. That didn’t help, after restarting the services, future attempt got me this error:

Error: 18456, Severity: 14, State: 58.

Message
Login failed for user ‘Domain\SPfarm’. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only.

So no dice. I kept searching and trying variations. Including altering my syntax to use the “username@domain.local” style but nothing worked.

I never did figure out how to get past the problem. I ran out of time and decided to go around the issue. I created the farm using the configuration wizard and then followed Cuban Pete’s instructions to change the name of the Admin Content database, which is simply the PowerShell commands needed to change the name in SharePoint and then when to go into SQL Server Managment Studio and change the actual database name.

Technorati Tags: command-line, psconfig, SharePoint

I was wrong. It went well. And he had a working 2010 farm with all the basic service apps in under 2 hours.

Here are some points to remember when doing a pilot (or any kind of) install:

• Create all of your service accounts ahead of time. (You DO use service accounts, right??)
• Give the setup account admin rights on the SQL servers too and not just the SharePoint servers (this wasn’t necessary for MOSS). If it’s SQL 2008, make the setup account a sysadmin in SQL. (The farm account still just needs “secadmin” and “dbcreator” roles in SQL.)
• Remember to turn off the “Default Web Site” in IIS. Also change the bindings so that the port is something other than 80.
• Get a static IP
• Don’t forget to disable the loopback check.
• If your SQL server hosts multiple projects and not just your SharePoint farm, consider using some kind of prefix in front of the database names as you are setting up SharePoint. For example, if you put “SP2010_” at the beginning of all the SQL databases you use, your SharePoint databases will be nicely bunched together when you use SQL Management Studio
• When setting up profile synchronization to Active Directory, try to only select OUs that have actual user accounts in them. Avoid the OUs or containers that have service accounts. Nobody wants to store 150+ profiles for service accounts.

Technorati Tags: consulting, IIS, security, SharePoint, working

Follow these steps to make the change manually:

1. Back up your registry (outside link)
2. Disable SSL 2.0:
   1. Browse to the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0" key. 
   2. There is probably a key there called "Client".  If there is not also a key under there called "Server", create it.
   3. Create a DWORD for the "SSL 2.0\Client" sub-key called "Enabled" and set it to "0".
   4. Create a DWORD value for the "SSL 2.0\Server" subkey and set it to "0", too.  (This will disable SSL version 2.0)
3. Enable SSL 3.0:
   1. Browse to the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\" key. 
   2. If there is not a key under there called "SSL 3.0", create it.
   3. Under "SSL 3.0", create a key called "Client" and a key called "Server".
   4. For both "Client" and "Server", add a DWORD value to each called "Enabled" and set it to "1" (This will enable SSL 3.0).
4. Enable TLS 1.0:
   1. Browse to the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\" key. 
   2. If there is not a key under there called "TLS 1.0", create it.
   3. Under "TLS 1.0", create a key called "Client" and a key called "Server".
   4. For both "Client" and "Server", add a DWORD value to each called "Enabled" and set it to "1" (This will enable  TLS 1.0).
5. Add support for the RC2, RC4, and 3DES ciphers:
   1. Browse to this key: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers"
   2. Under "Ciphers" you will add three keys.  The first is called "RC2 128/128".  The second is called "RC4 128/128".  The third is called "Triple DES 168/168".
   3. Do not add any values or keys under the three new keys.
6. Restart the server.

Or you could just run these commands from an administrative command-line:

REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f
REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f
REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 1 /f
REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 1 /f
REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 1 /f
REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 1 /f
REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Ciphers\RC2 128/128"
REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Ciphers\RC4 128/128"
REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Ciphers\Triple DES 168/168"

Further Reference:

• How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll (Microsoft Support)
• How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services (Microsoft Support)

Technorati Tags: command-line, IIS, security

Stuff that could make a difference:

• For Incremental crawls (of regular SharePoint content)
  • Farm architecture
    • Is the indexer (and/or the target server) host separated or doing other tasks?  If it’s doing other tasks, you must take into account the kind of load it’s under and when that load is high and low.
    • Is the database host(s) scaled in a way that running crawls don’t impact user traffic?
    • What’s your “Indexer Performance” level set to?
    • How fast does your indexer crawl?  (i.e. items per hour or items per day)
  • Content
    • How many items are currently (or at the time of go-live) in your index?
    • How frequent does it change?
    • What kind of content is it?  Big pdfs and Word docs?  SharePoint lists and news posts only?
    • What’s the anticipated growth rate of the content?
    • Are there any documented requirements for search freshness?

• For Full crawls (of regular SharePoint content)
  • Pretty much the same stuff as above
  • Can you get away with doing incremental only?  (See this TechNet page in the “Reasons to do a full crawl” section for info about when you must use full crawls instead of incrementals.)

• For profile import
  • Number of exposed profiles
  • Configuration of Mysites and number of mapped properties
  • Can AD handle the load?
  • Is the SSP server doing other roles?
  • Profile freshness requirements

Real life example:

The my current client projecthas pretty fast servers, 14+ million items in index, 40,000 users, and 4 WFEs.  We would be doing incremental crawls only if we can get around a technical issue.  Full crawls take about 4 days. (a bit over 4 million items crawled per day)  Until the problem is fixed, we have been doing full crawls once a week but we really can’t keep it up.  Incremental crawls happen nightly and are most often done before the work day begins. (This is unless users used Explorer View to move or change millions of items the previous day.)

As for profile imports, since MySites are not exposed for all 40,000 users, profile imports happen very fast.  Incrementals happen in under 20 minutes and fulls finish in a couple hours on Sunday mornings.  However, this summer we will expose SP 2010 mysites for all 40,000 users with some fairly moderate custom mappings.  When that happens we will be putting into some serious tuning focus to make sure that it happens efficiently. 

Here and here are some good tuning tips for MOSS… most are probably relevant for SP 2010 also.  Also, the “Inside the Index and Search Engines: Microsoft Office SharePoint Server 2007” book has been pretty helpful.

Technorati Tags: consulting, MOSS, SharePoint, SharePoint Search

BUT, in R2 of Server 2008, the most important one of these is locked down and won’t let you change it.  If you try to change the “IIS WAMREG admin Service” in R2 you’ll see a grayed out screen like this:

Even if you’re a full admin, you’re still locked out.  It turns out you have to into regedit and give yourself permissions to the corresponding registry key just to be ABLE to modify it in DCOM.  I found full instructions to fix it up in this blog post: http://www.wictorwilen.se/Post/Fix-the-SharePoint-DCOM-10016-error-on-Windows-Server-2008-R2.aspx

I had to pass this on.  Because I we’ll be running into this a lot as we get involved with MOSS installs on Server 2008 R2 servers.

Technorati Tags: security, SharePoint

Someone needed to move a Document Library from one site collection to another one.  The only viable way to do this is to go to the library settings for that doc library and export it as a list template with content.  When I did that I received the in-SharePoint error saying:

“The list is too large to save as a template. The size of a template cannot exceed 10485760 bytes.” 

This poses a problem because the only other (non third-party tool) way to do this would involve exporting a copy of the original site and then importing it into the destination site collection so that I would be able to use Site Manager to move the list.

Well it turns out there is an undocumented property that can be modified to change this.  Run the following command to see what your farm is currently set to:

stsadm.exe –o getproperty -propertyname max-template-document-size

Chances are the reply will be “<Property Exist=No" />”, which means that you are using the default setting of 10 MB as your limit.  You can set the limit to something higher by using the “setproperty” switch.  For example:

stsadm -o setproperty -propertyname max-template-document-size –propertyvalue 500000000

would increase the limit to about 60 MB.

In my case this was really a one-time thing so, after I had created the copy of the document library, I set the size back to the original 10485760 byte value.

Technorati Tags: command-line, SharePoint, stsadm