STSADM has survived in SharePoint 2010

I am going through some of the SharePoint Conference 2009 Videos I recently got from a colleague of mine that was lucky enough to be there, and I am pleased to have learned that STSADM will not be gone in SharePoint 2010. Simon Skaria confirmed this in his IT Pro Overview session.

Great. Now I don’t need to look for a new subtitle for my blog. [:D]

But I Simon Skaria also encourages everyone to move on to Powershell because of its auto-complete capabilities.

Update a SharePoint farm with minimal site downtime

It was the time of the year again to do an upgrade of several SharePoint farms for my customer. This upgrade was for installing SP2 and the June cumulative update on an entire farm and the requirement was to avoid too many downtime by the installation. This post will cover the process that I used to upgrade the entire farm.

Farm setup:
- 1 hardware load balancer
- 2 Web Front End servers (I will call the WFE1 and WFE2)
- 1 index server
- 1 SQL cluster

What I needed for upgrading the farm smoothly was a way to put a maintenance page for all web applications to appear when the content is really down. I used the simple ASP .Net trick by creating a – in my case custom -  App_Offline.htm file which mentions that the site is down for maintenance. Copying this file into the root location of each IIS website used by SharePoint Web Applications will show this message instead of the SharePoint content.

Another thing I wanted to do is to detach the databases before running the Configuration Wizard. Why? To avoid the upgarde to fail on a single content database and shorten the upgrade time. Once the config wizard completes, I reattach the content databases one by one, causing them to be upgraded at that moment.

preparation tasks:
- create a custom App_Offline.htm file for showing a maintenance page
- create a batch file that conveniently copies the App_Offline.htm file to all Web Applications (make sure not to copy it to the Central Admin WebApp) 
- create a batch file that conveniently deletes the App_Offline.htm file from all Web Applications 
- create a batch file that detaches all content databases for all Web applications with the exception of the Central Admin and SSP Web Apps ( add stsadm -o preparetomove command before detach database if you are still running MOSS SP1 pre-Infrastructure Update) 
- create a batch file that attaches the content databases

Upgrade process:

1.  Make sure that the hardware load balancers stops the services for WFE1 and only uses WFE2 to service user requests. We have an internal procedure that allows for manipulation of the load balancer. Actually we simply need to stop a custom IIS web site on the WFE server which will cause the load balancer to failover to the second WFE automatically.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 2 minutes

2. Install the binaries for your SharePoint upgrade on WFE1. In my case WSS SP2 + MOSS SP2 +  all SP2 versions of the WSS and SharePoint Language Packs and finally installing the June Cumulative Update for WSS and MOSS. When installation completes, reboot the server.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 50 minutes

3. Simultaneously install the same binaries on the index server. When installation completes, reboot the server.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 40 minutes

OK So far so good. So basically, at this point, I have installed the binaries on 2 servers and I still have 1 to go, which is WFE2 that is still serving the SharePoint sites. I have two possibilities to continue:
- option1: install the binaries on WFE2 and reboot
- option2: run the configuration wizard on the upgraded WFE1 or the index server.

Option 1 will take all the sites down, because the installation of new binaries will stop IIS = Downtime and 404 errors. I cannot redirect my users to the upgraded WFE1, because the configuration Wizard has not run yet. So I am working with option 2

4. on WFE2 I launch my script that sets all my sites in maintenance mode (copies the App_Offline.htm file, that is)
   Availability Result: Users are not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
   Timing result: this operation took 1 minute

5. on WFE2 I launch my script for detaching all content databases
   – this script launches a stsadm -o preparetomove command for each content database (except Central Admin and SSP databases). This command is no longer required if you have at least SP1 with the Infrastructure Update installed.
   – this script launches a stsadm -o deletecontentdb command for each content database (except Central Admin and SSP databases)
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
   Timing result: this operation took 5 minutes ( I had 5 content databases)

6. on WFE1, run the SharePoint Products and Technologies Configuration Wizard.
If the upgrade process fails, investigate the log specified by the wizard, but also check 12-Hive\LOGS\Upgrade.log and the default SharePoint ULS logs. I have already seen that the SharePoint logs are written to the 12-Hive\LOGS folder instead of the location you specified in Central Admin during this upgrade process. After the upgrade your specified Logging location is used again.
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
   Timing result: this operation took 15 minutes

7. Now that the farm configuration databases have been upgraded, your WFE1 is ready to start serving users again as soon as the content databases have been reattached. So, on WFE1 I launch my script to reattach the content databases. If one the operations generate an error, you can find the specific error in the 12-Hive\LOGS\Upgrade.log file.
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
   Timing result: this operation took 10 minutes.

8. Make sure that the hardware load balancers starts the services for WFE1 and stops the services for WFE2 to service user requests.
   Availability Result: Users are again able to access SharePoint content through WFE1.
   Timing result: this operation took 2 minutes

My upgrade status is now complete with regards to the SharePoint content. My farm is servicing users again through a single Web Frontend Server for the moment, but it is servicing which is my main concern at this point. I no longer have downtime towards my users. If you add up all the minutes, then I have had a downtime towards my users of 33 minutes, which can be considered a small downtime. Now I continue with the rest of the upgrade process.

9. WFE2 is free now to do with whatever I want since it is no longer included in the load balancer pool.
- first, I launch my script to deactivate the site maintenance which simply deletes all App_Offline.htm files
- Next, I Install the binaries for the SharePoint upgrade on WFE2 + Reboot the server
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 50 minutes

10. While WFE2 is installing the new binaries, I can run the SharePoint Products and Configuration Wizard on the index server.
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 6 minutes

11. Run SharePoint Products and Configuration Wizard on WFE2
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 8 minutes

12. Final step: Add WFE2 back into the load balancer pool

Conclusion:
Although the entire operation took about 4 hours, there was a downtime of only 33 minutes for our users and furthermore our users did not hit any 404 pages, but received a nice site maintenance page telling them exactly what is going on. Needless to say, that my customer was satisifed with the result for the downtime

Hopefully this process is of any use to you guys.

 

Sample of my script files as requested by KbNk:

The maintenance mode script and the de-reattach scripts are simple batch files (*.bat).

Here is a sample for the scripts:

example data:

-> 1 Web Application with url http://webapp1.contoso.local
-> SQL server name: sqlserver01
-> content database name for the webapp: wss_content_webapp1
-> IIS Site directory location on file system: E:\IIS\mywebapp

- maintenance mode on script = simple copy command, no rocket science
   copy e:\App_Offline.htm E:\IIS\mywebapp\

- maintenance mode off script
   del e:\IIS\mywebapp\App_Offline.htm

- detach database batch file sample:
   stsadm -o preparetomove -contentdb sqlserver01:wss_content_webapp1 -Site http://webapp1.contoso.local  (Remove this line if you have SP1 wth Infrastructure Update or later installed)
   stsadm -o deletecontentdb -url http://webapp1.contoso.local -databaseserver sqlserver01 -databasename wss_content_webapp1

- attach database bacth file sample:
   stsadm -o addcontentdb -url http://webapp1.contoso.local -databaseserver sqlserver01 -databasename wss_content_webapp1

Change the default 10 MB limit for saving a site as template

I bumped upon this 10 MB limit today when trying to save a site as a template. Did some research on the net and found that you can change this limit through the following stsadm command:

stsadm -o setproperty -pn max-template-document-size -pv 524288000

This will set a 500 MB limit instead, which is apparently the maximum value you can specify. 

Speed up SharePoint spin-up and stsadm execution time by Jeroen Ritmeijer

Here is the lifesaver of the month! Jeroen’s post was sent to me by Cedric Carrette (Thanks [:D]).


Original post content;


Ever since SharePoint 2007 was introduced I have been really disappointed with the 2 minute spin-up time of the sites and the 30 second wait when launching STSADM.

How could Microsoft have released this? I thought, What is wrong with these people? Why is there no uproar in the SharePoint Community at large?

As it turns out this problem does not occur on all SharePoint installations, it only happens under a certain combination of circumstances. Fortunately I have identified the root cause as well as a solution.

Symptoms for STSADM:


  • You start STSADM without any parameters
  • There is a delay of about 30 seconds
  • While you are waiting, and tearing your hair out because your deployment script has about 60 STSADM commands, there is no CPU activity, swapping or significant network traffic. 

Symptoms for SharePoint sites:


  • You make the first request of the day, the first request after yet another SharePoint crash or the first request after recycling the app pool because you are developing assemblies that sit in the GAC.
  • There is a delay of about 2 minutes
  • While you are waiting, and tearing your remaining hair out because you know you have to do this at least 50 times today as you are trying to work your way around the various event receiver bugs and limitations, there is no CPU activity, swapping or significant network traffic.

So, what is going on here? Quite a few, but not that many, SharePoint developers are complaining about this on the Internet, but no-one has a real solution. Is there a solution or should I start looking for a new job?

After yet another night of Googling around I found the solution in a posting about SQL Server 2005, which appears under certain circumstances to suffer from the same problem as SharePoint 2007. (Note that in my particular situation the problem is caused by SharePoint being slow, not SQL Server.)

The problem is that when loading signed assemblies the .net Framework checks the Internet based certificate revocation list. As our servers have, like most secure environments,  no outgoing connections to the public Internet the connection to crl.microsoft.com times out after what appears to be 30 seconds. It probably does this a couple of times in succession, causing a 2 minute wait when spinning up SharePoint.

After the timeout the assembly is still loaded and the software works as expected, though very slow every time a new signed assembly is loaded for the first time, which happens a lot. The worst thing is that no entries are written to the event log and no exceptions are thrown so you are left completely in the dark about why your application is so bloody slow.

There are a couple of workarounds, which one works best is for you to decide:


  1. Add crl.microsoft.com to your hosts file and point it to your local machine. Some people have reported success with this, but it didn’t work for me.
  2. Allow your servers to directly connect to crl.microsoft.com. If your environment dictates the use of a proxy server, configure it using proxycfg.
  3. Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Find yourself a group policy wizard to help you out or manually modify the registry:

    [HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
    “State”=dword:00023e00

     
  4. Download the CRLs and add them to the server manually (I haven’t tested this, but it may work):
     


    1. Download: http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
      http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
       
    2. Add them:
      certutil -addstore CA CodeSignPCA.crl
      certutil -addstore CA CodeSignPCA2.crl

We decided to go for Option 3 (disable CRL check) and life is good again….. well as good as it gets when you are doing SharePoint development.

Update – VBScript to apply registry change:

The following script applies the registry change to all users on a server. This will solve the spin-up time for the service accounts, interactive users and new users.

const HKEY_USERS = &H80000003
strComputer = “.”
Set objReg=GetObject(“winmgmts:{impersonationLevel=impersonate}!\\” _
   & strComputer & “\root\default:StdRegProv”)
strKeyPath = “”
objReg.EnumKey HKEY_USERS, strKeyPath, arrSubKeys
strKeyPath = “\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing”
For Each subkey In arrSubKeys
    objReg.SetDWORDValue HKEY_USERS, subkey & strKeyPath, “State”, 146944
Next


With thanks to Nik Shaw for the script.

Relevant links:

Change the Central admin port with stsadm

Hi all,


just this little tip for today. My colleague configured a test farm a while ago and let the wizard choose the port to be used for the Central Admin webapplication. I don’t know why, but every time I have seen this you get a hideous port from the wizard. So I changed the port to my preferred port number by using the following command:


Stsadm –o setadminport –port 5555


and that’s it. Nothing else to do, no restart, no iisreset, just this command.


I found this info on Shane young’s blog. Thanks for sharing Shane !

New SharePoint Admin and Management Tools by Joel Oleson

For those of you that are not subscribed to Joel’s blog (shame on you [H]).


This is one of a few Admin Tools that really help you batch changes.  This one appears to really be focused on batch changing site collections.  LOVE IT.  Thanks Zach, it’s about time :)  Just kidding.  I’m sure we’ll see more out of this Admin toolkit and we love what you’re doing so keep it up.

 

SharePoint Admin Toolkit

 

Batch Site Manager - Batch Locks, Moves, and Deletes for site collections in a nice GUI (100 at a time).

 

UpdateAlert – (STSADM extension) allows you to update alerts when your AAMs change (alternate access mappings or zones).

 

I looked at the white paper and highly recommend it for IT Pros.  Even if you don’t use the tool or don’t plan to, I was impressed by some good info on reference information on related STSADM commands with good resources related to the topics of Site Deletes, Moves, and Locks.  Move is very misunderstood.  This move is all about safely moving site collections between databases using timer jobs.  Very cool.  Don’t forget the commands that came in SP1 related to the STSADM command mergecontentdbs.  Good info there as well.  If you aren’t at that stage, it’s still a good reference… if you’re large you will eventually need to know this info.

 

Microsoft SAT SharePoint Cross Site Configurator 1.0 – For standardization and consistency of master pages, auditing, content types and more. What else do you want to use it for?

 

I love free tools, but sometimes you need to look for tools where you can even do more and get support.  Here’s some suggestions MOST of which are very NEW.  Even if you’ve looked, I suggest you look again at these released/supported tools.

 

 

DeliverPoint: Permissions is a new tool focused on user security and permissions in SharePoint.  It’s also a batch focused tool for making changes very pinpointed or in larger groups.  Moving, Deleting, Searching for User or Object permissions, and Cleanup/Dead Account Removal.  There’s a 14 day trial download.

 

AvePoint DocAve 4.5 SharePoint Administrator - Centralized multi farm administration of configuration.  “propagate configuration and security permissions to web applications, sites, folders, and lists in bulk, resulting in quicker time-to-value of each update.”  I got a demo of this from TJ in Dubai.  It was very impressive and I’d take a second look if you have or haven’t seen it.  There’s an eval copy on their site.

 

Quest Site Administrator – reporting on storage, usage, manage quotas and locks and enforce configuration and settings in “policies” in a centralized UI.  (Poorly named, it isn’t just site level managment it’s more farm wide management of sites.)

 

iDevFactory Universal SharePoint Manager - Centralized management UI exposing permissions, security, and easy console for managing settings and configuration.

stsadm -o enumusers explained – update

I came across some odd behaviour with the stsadm -o enumusers command. As it seems it does not enumerate the users of a site collection as expected. After doing some research I found a white paper from the guys of Mindsharp explaining this function as follows:

stsadm.exe -o enumusers -url <url> displays dead users, which is defined as users who no longer have a user account listed in the SharePoint profile database, but is still displayed in the site’s membership. For example, dead users can include users who have left an organization and have been removed from Active Directory. This parameter works on a site-x-site basis. the Enumusers command may also return the system Account (SHAREPOINT\system) shich is not a valid AD user”

The complete white paper about managing SharePoint using stsadm can be found here

I thought some of you would want to know about this.

As mentionned by Chris as a comment to this post,

“enumusers lists users on your site that have explicit permission levels set.  You will see these users listed on the permissions page (_layous/user.aspx), with their specific user permission level.” (http://technet.microsoft.com/en-us/library/cc263220.aspx)

I must say, that I will agree with Chris’ explanation and therefore must assume that the guys from Mindsharp were and are not. Stranegly enough their whitepaper stating this is still online. 

Thanks Chris [:D]

 

Configure Moss using psconfig.exe and stsadm

If you have read my post on configuring moss to use a database in an untrusted domain adn have tried it out, you will have noticed that the configuration of MOSS is not yet complete. Actually when running the Config wizard you can see 9 steps being performed. If you used psconfig to create or connect your server to a database, then there are only 3 steps performed.


So here are all the commands for setting up your MOSS using psconfig. The information is based on a blog article I found from Alpesh Nakar


Of course these commands will not work if you are not in c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN or have not added this path in your environment variables yet.


psconfig.exe -cmd configdb -create -server <SQL Server name> -database <database name> -user <AD user account> -password <AD user password>
 ( if you are adding an additional server to a farm, replace -create by -connect and stop after the command psconfig -cmd installfeatures)


psconfig -cmd helpcollections -installall


psconfig -cmd secureresources


psconfig -cmd services -install


psconfig -cmd installfeatures 


psconfig -cmd adminvs -provision -port 8000 -windowsauthprovider onlyusentlm


psconfig -cmd applicationcontent -install


Now Alpesh also gives you the stsadm commands to go and finish up the rest of the Moss configuration:


**SetupServices**
stsadm -o osearch -action start -role indexquery -farmcontactemail [email protected] -farmserviceaccount domain\username -farmservicepassword password -defaultindexlocation “C:\Program Files\Microsoft Office Servers\12.0\Data\Applications”


This starts your Office Search Services.


**CreateSSP**
stsadm -o extendvs -url http://%computername%:8100 -ownerlogin domain\username -owneremail [email protected] -exclusivelyusentlm -apidname “OurSSPon8100″ -apcreatenew -apidtype configurableid -apidlogin domain\username -apidpwd password


stsadm -o extendvs -url http://%computername%:8200 -ownerlogin domain\username -owneremail [email protected] -exclusivelyusentlm -apidname “MySiteson8200″ -apcreatenew -apidtype configurableid -apidlogin domain\username -apidpwd password


stsadm -o createssp -title “Shared Service Provider” -url http://%computername%::8100 -mysiteurl http://%computername%:8200 -indexserver %COMPUTERNAME% -indexlocation “%Programfiles%\Microsoft Office Servers\12.0\Data\Applications” -ssplogin domain\username -ssppassword password


**CreateSiteCollection**
stsadm -o extendvs -url http://%computername%:80 -ownerlogin domain\username -owneremail [email protected] -exclusivelyusentlm -apidname “SiteCollectionon80″ -sitetemplate SPSPortal -apidtype configurableid -apidlogin domain\username -apidpwd password


This will setup your webapps for shared services, my sites, create shared service provider and create your site collection as well.


That’s it.

Are your alerts not sending email? Use these stsadm commands to verify your alert settings.

I recently had a colleague asking me to troubleshoot some workflows. Apparently the workflow should send emails, but nothing was coming thru.


As part of my troubleshooting I came across 2 stsadm commands that may help you identify an issue with your alerts.


Although these commands did not help me solve the issue (a reboot of the Frontend did [:D] ), I found these commands worth writing down in a post:


First command:


stsadm.exe -o getproperty -url <http://problemsite> -pn alerts-enabled
this command should return: <Property Exist=”Yes” Value=”yes” /> which means that alerts are good on the site


Second Command:


stsadm.exe -o getproperty -url <<http://ProblemSite>> -pn job-immediate-alerts.
this command shoud return: <Property Exist=”Yes” Value=”every 5 minutes between 0 and 59″ />


What else can you do to troubleshoot?


Open the MOSS Central Administration page, click Operations–Timer Job Status,

make sure the following two jobs are showing “success” and 100%
Change Log
Immediate Alerts


 

Site Template identifiers for use with STSADM

For those CLI geeks out there like me I really enjoy using stsadm for creating new site collections, etc. One of the things I always keep looking for are those identifiers for specifying the site template for the new site collection. I have gathered a list now of available ones and give them to you with this post.


GLOBAL#0 = Global template
STS#0 = Team Site
STS#1 = Blank Site
STS#2 = Document Workspace
MPS#0 = Basic Meeting Workspace
MPS#1 = Blank Meeting Workspace
MPS#2 = Decision Meeting Workspace
MPS#3 = Social Meeting Workspace
MPS#4 = Multipage Meeting Workspace
CENTRALADMIN#0 = Central Admin Site
WIKI#0 = Wiki Site
BLOG#0 = Blog
BDR#0 = Document Center
OFFILE#0 = Records Center
OFFILE#1 = Records Center
OSRV#0 = Shared Services Administration Site
SPS#0 = SharePoint Portal Server Site
SPSPERS#0 = SharePoint Portal Server Personal Space
SPSMSITE#0 = Personalization Site
SPSTOC#0 = Contents area Template
SPSTOPIC#0 = Topic area template
SPSNEWS#0 = News Site
CMSPUBLISHING#0 = Publishing Site
BLANKINTERNET#0 = Publishing Site
BLANKINTERNET#1 = Press Releases Site
BLANKINTERNET#2 = Publishing Site with Workflow
SPSNHOME#0 = News Site SPSSITES#0 = Site Directory
SPSCOMMU#0 = Community area template
SPSREPORTCENTER#0 = Report Center
SPSPORTAL#0 = Collaboration Portal
SRCHCEN#0 = Search Center with Tabs
PROFILES#0 = Profiles
BLANKINTERNETCONTAINER#0 = Publishing Portal
SPSMSITEHOST#0 = My Site Host
SRCHCENTERLITE#0 = Search Center
SRCHCENTERLITE#1 = Search Center
SPSBWEB#0 = SharePoint Portal Server BucketWeb Template