A couple of weeks ago I was asked to help troubleshoot problems with a Microsoft Project Server 2007 environment. After looking into the details, it seemed clear the problem only occurred on large projects. It also felt like a timeout. The message was:

Project Center cannot access the project(s) you are trying to view. It is most likely that you either don’t have permissions to view the project, another user has deleted this project(s) before you were able to view it or that another user is in the process of publishing the project.

I will not dive into Project Server troubleshooting here, because main reason of this error message was the lack of SQL maintenance. The databases were in bad shape, causing all database related tasks much longer to complete (in this case too long).

This is not Project Server specific though. Every SQL Server should be setup to run some maintenance on a regular basis. In SQL Server, this is done by Maintenance Plans. Although I’m not a certified DBA, I think it is safe to share a basic maintenance plan. Use at your own insights.

Requirements:

• SQL Server Management Studio
• SQL Server Agent running and set to start automatic

So here goes:

1. Open SQL Server Management Studio
2. Navigate to Management > Maintenance Plans
3. Right click on the folder Maintenance Plans and choose Maintenance Plan Wizard
   
4. The Wizard will speak for itself mostly…
   
5. Provide a name
   In this case, I will create a weekly plan for the User databases. The User databases are all databases that are not System databases (master, model, msdb and tempdb). The System databases do not require the same extensive maintenance)
   
6. Create a schedule for the plan to run
   
7. Select tasks to be run
   
   In this case, I chose the following: 
   1. Check Database Integrity
      Make sure the database is consistent, if not we have a serious problem
   2. Rebuild Index
      Ideally you would check for fragmentation first, and then choose between Reorganize of Rebuild
   3. Update Statistics
      Not always necessary,  for instance SharePoint has timer jobs that perform this tasks
   4. Backup (Full and Transaction Log)
      Speaks for itself
   5. Maintenance Cleanup Tasks
      Clean up some old logfiles or backups
8. Set the right order in which the tasks will be run
   
9. Set options for the Integrity Check
   In this case I selected All User Databases (newly created databases are added automatically)
   
10. Set options for Index Rebuild
    
11. Set options for Update Statistics
    
12. Set options for Backup Databases
    Note that you can check to create subfolders per database. Also, I selected to verify the backup (which will cause the tasks to run longer)
    
13. Set options for Backup Database Transaction Log
    Same options as previous task. Note that system databases do not have transaction logs
    
14. Set cleanup options
    We can choose to have the tasks remove old backups or logfiles.
    
15. Write a logfile of the maintenance plan and/or send a report by email (if database mail is configured)
    
16. Review and test
    

Considerations:

• A consistency check can be done on a daily basis, while Index or Statistics operations would only need to run once a week or so
• Test the plan. See how much time it takes to complete
• Test the plan. See how it impacts performance. Index operations can be very heavy
• Monitor. Review logfiles. It’s nice to have these tasks automated now, but how will you know if a consistency check failed?
• Maintenance plans are run by the account that created or modified them. Consider the account you use to create these plans.

I hope this helps in having more healthy SQL Servers. It’s like fitness and yoga for your databases

##
# Set BrowserFileHandling on all document libraries in all webs
##

param([string]$SiteName = “http://intranet”, $Path = “C:\PowerShell-Log.rtf”)

Start-Transcript -Path $Path -Append

$Site = Get-SPSite($SiteName)

# Root Web
$Web = $Site.OpenWeb()
Write-Host -BackgroundColor Magenta “Opening Web ” $Web.Url
foreach ($List in $web.Lists) {
    Write-Host ” Opening List ” $List.Title
    if($List.BaseType -match “DocumentLibrary”) {
        if($List.BrowserFileHandling -eq “Strict”) {
            $List.BrowserFileHandling = “Permissive”
            $List.Update()
            Write-Host -ForegroundColor Green ”  BrowserFileHandling set to Permissive”
        } else {
            Write-Host -ForegroundColor Yellow ”  BrowserFileHandling already set to Permissive”
        }    } else {
        Write-Host -ForegroundColor Cyan ”  List is not a Document Library (” $List.BaseType “)”
    }
}

# Sub Webs
foreach ($Web in $Site.AllWebs) {
    Write-Host -BackgroundColor Magenta “Opening Web ” $Web.Url
    foreach ($List in $web.Lists) {
        Write-Host ” Opening List ” $List.Title
        if($List.BaseType -match “DocumentLibrary”) {
            if($List.BrowserFileHandling -eq “Strict”) {
                $List.BrowserFileHandling = “Permissive”
                $List.Update()
                Write-Host -ForegroundColor Green ”  BrowserFileHandling set to Permissive”
            } else {
                Write-Host -ForegroundColor Yellow ”  BrowserFileHandling already set to Permissive”
            }
        } else {
            Write-Host -ForegroundColor Cyan ”  List is not a Document Library (” $List.BaseType “)”
        }
    }
}
Stop-Transcript

So, I booked the exam on Monday evening and  scheduled it for the next morgning. No time for second thoughts Despite the fact that I do not know all PowerShell commandlets and Central Andmin options by heart, I did manage to pass the exam with 816 points. I would have liked a better score, but then I should probably have done some preparing…

On to the 70-668 exam

More details can be found on the e-office website. It’s a free event and will be hosted in Houten (Netherlands) on August 17, from 09:00 to 13:00.

I hope to see you there!

Following the Technet documentation we were able to migrate our sites, using SQL backups en Mount-SPContentDatabase. This results in a mounted Content Database that can already be accessed. But, it seems there is another step to take which as of yet is not mentioned in every Technet article. When moving from Classic Authentication to Claims Based Authentication, we also have to migrate our user info. Makes sense, but this was only mentioned in context with Forms Based Authentication, which is why I never read it.

So, when migrating from Classic Authentication to Claims Based Authentication, here are the steps:

1) Restore your SQL databases to your SQL server
2) Make sure the farm account has DBO permissions on these databases
3) Create your CBA Web Application in Central Admin or PowerShell
4) Run Test-SPContentDatabase and fix any possible errors
5) Run Mount-SPContentDatabase
*) If you are in a cross-domain environment, run the stsadm -o setProperty -pn PeoplePicker-SearchADforest command (see details)
6) Migrate users through PowerShell:
$WebApp = Get-SPWebApplication https://mywebapp
$WebApp.MigrateUsers(“True”)

That’s all! Remember that, before step 1, you need to run your checks on the SharePoint 2007 environment. SP2 for MOSS added the stsadm -o PreUpgradeCheck command, which checks for any possible issues you might encounter when migrating to SharePoint 2010. This is a crucial step to your migration!

I hope this helps in better migrations

Both users have the same permissions on the sites. The user from internal.local can browse through all the sites and view all the content. I even tried to make the user Site Collection Admin. No results were shown. Firewalls temporary disabled, nothing.

The problem seems to lie in the domain trust. SharePoint 2010 has a lot more issues regarding domain trusts then SharePoint 2007. After a lot of searching, the final answer came from Johan Kroese: the Search Service Application needs to store it’s ACLs as Claims.

Of course, PowerShell can help us with that:
$SearchApp = Get-SPServiceApplication SearchAppName
$SearchApp.setproperty(“ForceClaimACLs”, 1)
This command is undocumented for as far as Google knows, but the implications seem quite clear: the ALCs are now stored as Claims instead of NT tokens.

After that, you also need to migrate your Web Application to Claims Based Authentication. If you are already running in Classic mode, here’s the PowerShell code to switch to CBA:
$WebApp = Get-SPWebApplication https://mywebapp
$WebApp.UseClaimsAuthentication = “True”
$WebApp.Update()
This is a one-way migration, you cannot go back to Classic mode!

This resulted in the desired behavior: the user from internal.local could see all the search results.

Once again saved by the community, thanks Johan!

The problem with the People Picker is this: SharePoint does not resolve account names from the other (trusted) domain. It just cannot find it. You can open the firewall any way you like, it’s not going to happen. It won’t even try to contact the domain controller from the other domain. We need to tell SharePoint that it should search in other domains too. As of today, there doesn’t seem to be a PowerShell command to do this, so we’re going old school with stsadm.

First, we set an encryption key (execute this on each server in the farm):

stsadm -o setapppassword -password ******

 Second, we register all the domains that need to be searched for account names (this is done per Web Application, not per server)

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domainB.local;domain:domainA.local,domainA\account,password -url http://webapplication

That should be all! Remember that at least firewall ports 88, 139 and 445 should be open.

This particular problem is not SharePoint 2010 specific, SharePoint 2007 has the same issue. It is strange however that there is no PowerShell replacement for this. The need for cross domain name resolving is just as present today as it was 3 years ago, if not higher.

After the release of the VLK bits last Friday and the Dutch Language Pack this Monday, we now had the right tools to move to the new 2010 wave. We had enough experience with the MSDN bits, but going to production you will need VLK (or non-dev licenses). Just as a side note: installing SharePoint 2010 (on any number of servers) is a breeze with AutoSPinstaller, which can be found on CodePlex.

To get an idea of what Office Web Apps is, visit the Microsoft website. I’m really crazy about it, because it allows people to view content very quickly, without opening additional client applications or even without requiring a rich desktop. You can use any kind of tablet, you don’t need powerful hardware or expensive licenses. You don’t need to wait on applications to launch and authenticate. It’s fast. Just click on a document and off you go. Now that’s making things easy…

Speaking of easy, installing and configuring Office Web Apps is like launching Microsoft Paint (hint: hit Windows key, type Paint, press Enter). All you need is an up and running SharePoint 2010 farm (psconfig should be completed).

Start installation by running Setup.exe on each server in the farm. Remember to configure the location for the cache, storing this on the primary disk may decrease performance. Some services will be restarted, so make sure no users are active. After setup completes, the SharePoint Products Configuration Wizard needs to run. You don’t need to configure anything here, just make sure setup has run on every server in the farm before running this wizard.

After this wizard has run on the servers, it’s time to configure. Up until now all we have done is installing the bits (using about 5 mouse clicks). Configuration can be done using Central Administration, but I prefer PowerShell. Much quicker and easier to reproduce. Basically, the steps are: (1) start services, (2) create service apps, (3) profit.

Starting the services is easy. A quote from Technet:

$machinesToActivate = @("contosoapp1", "contosoapp2")
$serviceInstanceNames = @("Word Viewing Service", "PowerPoint Service", "Excel Calculation Services")
foreach ($machine in $machinesToActivate)
  {
  foreach ($serviceInstance in $serviceInstanceNames)
  {
    $serviceID = $(Get-SPServiceInstance | where {$_.TypeName -match $serviceInstance} | where {$_.Server -match "SPServer Name="+$machine}).ID
    Start-SPServiceInstance -Identity $serviceID 
  }
} 

All we need to configure here is the first line: enter the names of the servers that need to run the application side of the Office Web Apps.

Next, creating the Service Applications is also easy.

$appPool = Get-SPServiceApplicationPool -Name "SharePoint Web Services Default"
New-SPWordViewingServiceApplication -Name "WdView" -ApplicationPool $appPool | New-SPWordViewingServiceApplicationProxy -Name "WdProxy"
New-SPPowerPointServiceApplication -Name "PPT" -ApplicationPool $appPool | New-SPPowerPointServiceApplicationProxy -Name "PPTProxy"
New-SPExcelServiceApplication -Name "Excel" -ApplicationPool $appPool

This will create 3 Service Applications (for Excel, PowerPoint and Word; OneNote does not need a Service Application). You might want to change the Application Pool that will be used for this.

From now on, all Site Collections that will be created will have the features for Office Web Apps activated. To activate these features for all existing Site Collections, run the following script:

$webAppsFeatureId = $(Get-SPFeature -limit all | where {$_.displayname -eq "OfficeWebApps"}).Id
Get-SPSite -limit ALL |foreach{Enable-SPFeature $webAppsFeatureId -url $_.URL } 

That’s all! You can’t really do much wrong here, but as with everything: running with the default might give you some surprises in the future. Spend some time reading Technet on this subject. It’s only a couple of pages on understanding, planning and deploying.

A nice bonus for international users: there is only one Language Pack needed for SharePoint (Foundation and Server), Project Server and Office Web Apps. No need to install additional Language Packs for Office Web Apps.