I’m trying to figure out what direction to go with my next posts. But what I really need is to commit to some consistency. My employers are asking me to contribute to the corporate blog so there is a lot of positive pressure to write more.
But what to post? Do you like instructional how-to stuff or do you like contracting consulting interviewing wisdom? You don’t have to answer but these are what’s warbling in my head.
If you have to build enough SharePoint 2010 environments after a while you get really tired of manually adding every service account in SharePoint Central Administration.
Below is some PowerShell code that can be used to load up all of your service accounts at once. You’ll have to change some things if you have different passwords for each account or if you need to enable automatic password changing.
### This script is for bulk loading SharePoint managed service accounts that
### are in the same domain as the server and all have the same password.
#
# Enter the one password for all accounts betweenthe quotes in the line below
$password = "Cryp7icP@ssword"
$securePassword = ConvertTo-SecureString -String $password -AsPlainText -Force
#
# Put each service account to be SharePoint managed in double quotes like the example below
ForEach ($SvcAccount in "SVC-SPSearch","SVC-SPServiceApp1","SVC-SPBCS","SVC-SPProfileImport","SVC-SPPortalAppPool","SVC-SPMysiteAppPool") {
$userName = $env:USERDOMAIN + "\" + $SvcAccount
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList $username, $securePassword
New-SPManagedAccount -Credential $cred -whatif
}
This comes up all of the time for me and it is high time that I created a single place for me to see every antivirus exclusion that is necessary for production SharePoint 2010 and SQL 2008 R2 servers to run efficiently. If you don’t configure antivirus exclusions on your servers you can expect to see performance problems and mysterious errors at some point, especially when load starts getting high.
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:
Simply put, no.
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.
As I’m preparing to start work on building a single-server SharePoint 2010 pilot rig for a client, I was listing things to check for before I would be willing to shoot off my mouth about how easy the installation will be.
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:
I had four clean Windows 2008 R2 installed servers all in a row fail when installing Forefront Unified Access Gateway with the same error:
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.
On a client’s site today I was having a horrible time trying to use psconfig to create a configdb. The reason I was doing it is because the client wanted every SharePoint database to have a certain prefix on the database name. You can use the configuration wizard to customize the name of the configdb but it doesn’t let you customize the name of the Central Admin site’s content database. To do that, you need to use PSconfig.exe. No problem, I’ve done this before; sometimes for this exact reason.
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:
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 FancyPrefix_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.
After running WordPress for several years, I just today activated the Hello Dolly plugin.
I have to say, it really does lighten the mood… as advertised.
There used to be a time when it was easy to search for Active Directory users or security groups or computer names. Back in Windows 2000 it was easy but now you need a dozen clicks to get XP or Windows 7 to let you search Active Directory. Lucky for you you can make a quick shortcut to get you there.
Create a new shortcut and make the destination:
%windir%\system32\rundll32.exe dsquery.dll,OpenQueryWindow
Give it a memorable name like “Active Directory Search” and consider changing it to a snappier icon and boom, there ya go. Now you can search through all of the users, contacts, groups and even containers if you use the advanced tab.
I had a one-day quick gig yesterday where the client had a blanked VM ready and an existing SQL server. He wants to show his users and stakeholders what SharePoint 2010 looks like but doesn’t really know what his or their needs are. I assumed that, like all unplanned and undocumented installations, there would be some unforeseen roadblock and I would need more than the one day I was given. Also, I assumed that if the client wanted to drive or backseat drive the install that it would take much longer.
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: