Links to Free SharePoint 2010 Training Resources

June 25, 2012 Leave a comment

Lunch and Learn site –

Very corny videos – meant for user adoption, not training. There are good ‘How Tos’ after the videos.
Also has MySite introduction. All the Show me how videos use Office 2010.

Good case studies and business uses

Search overview is excellent.

 Training at your desk!

This is very good – but uses Office 2010 which might be different than what your users have.

Office Videos

The first two are the best ‘intro’ type videos.

SharePoint Ribbon
Team Work – docs, tasks, calendars

How to use with PowerPoint

Creativity Hub

This a SharePoint site you can host that has user directed training. Also has content for Office 2007 / 2010 so the site could be used for that too. The site remembers which courses each user has taken. Very good content.

Interesting Technical Training

Categories: SharePoint 2010 Tags: , ,

Active Directory Migration and SharePoint

June 22, 2012 Leave a comment

Everyone should have to go through an Active Directory migration at least once in their career – you really learn how much you don’t know!


Create a test farm in the old domain that mimics your production farm as much as possible. Pay special attention to the service accounts. Create new accounts for each service account in the production farm, and use them in the test farm. Bring at least one content database over (backup / restore to the testfarm, then attach). Hopefully, you can do this with virtual machines, so that once you get your testfarm up and running you can snapshot it. Run the migration tools and move the testfarm servers to the new domain. Much better to try to figure things out in a testfarm than at 2 AM in a production environment!


We migrated a small SharePoint 2007 farm (1 WFE/App server, 1 DB server). We used the Quest Migration Manager for Active Directory to do the heavy lifting. NOTE – every environment is different. As the saying goes, your mileage may vary.

Migrating Users

For many reasons, we moved users in phases. We also migrated the users and their machines first, and then migrated the servers (this is a debatable decision – things might have been smoother doing the servers first).

When a set of users is migrated, they are now logging in as newdomain\username, but their permissions / ownership / mysite etc. are still olddomain\username. To SharePoint these are two different users.  So, as users are migrated, you must run this STSADM command

stsadm.exe -o migrateuser -oldlogin olddomain\username -newlogin newdomain\username

This replaces the old account SID in the SharePoint databases with the new account SID – everything works. However, we did have the joy of having some ‘roaming’ users who used workstations in different locations. We did not identify them as we should have, and had all sorts of trouble when only one of their workstations was migrated. When they used the other non-migrated workstation they had no SharePoint access (other than Authenticated User). For these people, we manually added their olddomain\username to sites for which they needed access. After the migration was complete, we reran the migrateuser command on their accounts to fix things up.

Migrating SharePoint Servers

SharePoint sites worked correctly after Quest tool processing and migration of the server to the new domain. The tool did a great job creating newdomain\serviceaccounts in SQL Server, and giving them the proper roles and rights. However, the tool does not change the dbo for the SharePoint content databases to the newdomain accounts – this must be done manually.

One thing to note – the Quest tools allows you to do processing before the server is migrated. However, do not do the IIS processing on the WFE before you intend to migrate the server because the AppPool accounts will get changed to the new domain accounts – which will break SharePoint because they will not have DB access.

Running the recommended processing in the Quest tool and migrating the server worked pretty well. SharePoint sites were accessible and functional. However, these issues needed addressing (same ones we found when we tested) –

  • Search did not return any results.
  • Accessing the Central Admin site pages “Manage Applications” and “Operations” returned an Access Denied error.

Fixes were very easy and straightforward.

To fix the Access Denied errors

Logon to a Web Front End server. Open a command prompt, and navigate to the SharePoint 14 hive, bin directory. Run this command –

stsadm -o updatefarmcredentials -identitytype configurableid -userlogin <new domain>\admin_account –password *******

iisreset /noforce

To fix the search problem

Use the Central Admin web site to navigate to the Search Administration page (in the Shared Service Provider). Select “Default content access account” and change the domain on the account listed to the new domain. Start a new crawl (incremental is OK).

PowerShell Script to Backup Site Collections

May 2, 2012 2 comments

This script will create a backup for every site collection. The directory name  that contains the site collection backup is the GUID for site collection (the log file contains the mapping for GUID to URL). Make sure the backup location is shared so that the process can write.

This code shows how to remove particular site collections from the backup. It also prunes the number of backups that kept by deleting all backup folders older than 7 days.

# Backup all site collections in the farm, placing them in 
# a directory on a shared location
# Note - Does not backup the /train site collection
Add-PsSnapin Microsoft.SharePoint.PowerShell

# Take care of the disposable objects to prevent memory leak.
Start-SPAssignment -Global

# This is the backup path - must be shared

# Remove all that backup folders created > 7 days ago
get-childitem $backupLocation | 
     where {$_.Lastwritetime -lt (date).adddays(-7)} | 
     remove-item -recurse -Confirm:$false

# Get current date for use in log file and format it to avoid 
# invalid characters such as "/" and ":"
$today=Get-Date -format "MM-dd-yyyy"

# Create a folder in the backup location with todays date (sortable)
$todayFolder = $backupLocation + '\' + $((get-date).toString('MM-dd-yyyy'))
md $todayFolder

# Does not backup the /train site collection
# or the temporary web ap site collection on port 15702
foreach ($site in get-spsite -limit all | 
         where-object -FilterScript {$_.url -notlike "*/train*"} | 
         where-object -FilterScript {$_.url -notlike "*15702"}) {
    write-Host Start backing up $site to $todayFolder
    try {
         # Create a new backup file and name it based on current date.
         # If you want to create only 1 backup file and overwrite it
         # each time the backup is run, you can replace "$today.bak"
         # with your desired file name.
         $pathName = ($todayFolder + '\' + $($site.ID) + '.bak')
         write-Host 'Backing up ' $site ' GUID = ' $($site.ID)

         # This farm does not have Enterprise SQL Server, so snapshots 
         # cannot be used. This requires that the sites belocked for 
         # update during the backup, so this should be run after hours
         Backup-SPSite -Identity $site -Path $pathName -EV Err 
            -EA "SilentlyContinue"
         write-Host Backup succeeded.

         # Write success message to the log file
         write "$today $site GUID = 
           $($site.ID) successfully backed up.">>logFile
    } catch {
        write-Host Backup failed. See $logFile for more information.
        # Write error message to the log file
        $e = $Err[0].ToString()
        write "$today $site Error: $e">>logFile
Stop-SPAssignment -Global
Remove-PsSnapin Microsoft.SharePoint.PowerShell
write-Host "Finished script."
Categories: SharePoint 2010

Runaway WMIPRVSE.EXE Process

April 27, 2012 Leave a comment


W2K3 machine


SharePoint was running slower than normal. Logged onto the WFE, opened Taskmgr.exe and found that the CPU was pegged. The culprit was the WMIPRVSE process.


After some investigation and restarting services, these are the steps that worked:

  • Kill the runaway process WMIPRVSE.EXE
  • Open Services.msc
  • Restart ScriptLogic CBM Service
  • Restart Window Management Instrumentation (which also restarted Citrx tools for Virtual Machines Service)

Because this server is due for retirement (after migration to SharePoint 2010), no further investigation of why the problem occurred was warranted.

Categories: SharePoint 2007

SharePoint 2007 AD Migration – Test

April 26, 2012 Leave a comment

Project – Test migrate SharePoint 2007 (MOSS) to a new Active Directory domain

  • Test farm has two servers – WFE and Database.
  • Quest Active Directory Migration Manager used to move server to new domain.
  • System accounts created in new domain with same rights on server as old domain accounts (Quest tool).
  • SQL Server Users created with accounts in the new domain with same database rights as the old domain accounts (Quest tool).


NEWDOMAIN\svc_admin_sp2 – can access Shared Service Provider (SSP) pages, but not Operations or Application Management in Central Admin.


Logged in to WFE with ID that could access Operations pages in Central Admin (OLDDOMAIN\svc_admin_sp2)

Run STSADM command to update the farm credentials –

Updates the Web application pool for the SharePoint Central Administration Web site and the Windows SharePoint Services Timer service (SPTimer).>

stsadm -o updatefarmcredentials -identitytype configurableid -userlogin NEWDOMAIN\svc_admin_sp2 -password


Crawl not working.


Default content access account = OLDDOMAIN\svc_admin_sp2

Changed content access account to NEWDOMAINk\svc_admin_sp2 using Search Admin page

Started full crawl

Access OK – no errors in crawl log

Also ran these – which did not fix the problem but where run first and might be needed

Ran STSADM command migrate user for both accounts – had to be logged in as OLDDOMAIN\svc_setup_sp2 – with NEWDOMAIN\svc_setup_sp2 account got an Access Denied error.
Logged in as OLDDOMAIN\svc_setup_sp2 on SRV3 (DB server) – added NEWDOMAIN\svc_admin_sp2 to Farm Admin group (was missing).
Changed application pool accounts – logged in as OLDDOMAIN\svc_setup_sp2

Performed for LINC (the name of the main Web Application) and SSP
Checked Database rights with Magenium SharePoint Farm – all OK. However, the name of the Schema objects is not changed. For example – the NEWDOMAIN\svc_admin_sp2 login owns the OLDDOMAIN\svc_admin_sp2. I don’t think this is a problem.