Office Web Apps Administration

Hi,

alle wichtigen Office Dokumente im Browser anschauen - unabhängig von der Client Version. Mit Office Web Apps und SharePoint 2010 ist dieses Szenario sehr einfach realisiert. Die Installation und Konfiguration der Dienstanwendungen in SharePoint ist kein nennenswerter Aufwand. Auch die Administration ist für einen SharePoint Admin keine sehr großer Bedrohung - wenn man denn weiß was zu tun ist :-) Eine der Stellschrauben, die all zu oft vergessen werden ist der Cache der Office Web Apps. Office Web Apps laden jedes aufgerufene Dokument in den Cache - das erhöht die Geschwindigkeit des Renderings wesentlich! Nun kann man sich vorstellen, dass der Cache recht schnell einiges an Platz auf der Platte nimmt. Diesen Platz gilt es im Auge und unter Kontrolle zu halten!
Dafür gibt es einen lesenswerten TechNet Artikel. Zusammengefasst gilt es folgendes zu beachten:

• Der Cache wird einmal pro Webanwendung angelegt,
• der Cache wird automatisch in eine Websitesammlung abgelegt und somit in eine SharePoint Inhaltsdatenbank.

Eingestellt werden kann am Office Web Apps Cache:

• Die maximale Größe,
• das Ablaufdatum.

Mit beiden Einstellungen kann man schon dafür sorgen, dass einem der Cache nicht über den Kopf wächst. Nun will man den Cache aber auch nicht unbedingt in seiner produktiven Inhaltsdatenbank und somit auf seinen Datenbanksicherungen. Daher sollte in der Routine zum Anlegen einer neuen Webanwendung direkt enthalten sein, den Office Web Apps Cache in eine eigene Inhaltsdatenbank umzuziehen. Das kann man natürlich mit der PowerShell erledigen ( wie es der Artikel schon sehr gut beschreibt ).

Ich habe mir folgendes Skript daraus geschrieben, mit dem jeder Admin in der Lage sein sollte, die Wartung des Web Apps Caches vorzunehmen ohne sich die einzelnen Befehle suchen und bearbeiten zu müssen.

1. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)   
2. {   
3.     Add-PSSnapin Microsoft.SharePoint.PowerShell   
4. }   
5.   
6.     $webAppUrl = Read-Host "URL of the Webapplication"  
7.     $DBServer = Read-Host "Database Server"  
8.     $CacheSize = Read-Host "Max Cache Size GB"  
9.     $expirationDays = Read-Host "Expiration Period in Days"  
10.        
11.     Write-Host "..."  
12.     Write-Host "Your Web Application: " -nonewline; Write-Host $webAppUrl -ForegroundColor Yellow    
13.     Write-Host "Your Database Server: " -nonewline; Write-Host $DBServer -ForegroundColor Yellow    
14.     Write-Host "Your Cache Size in GB: " -nonewline; Write-Host $CacheSize -ForegroundColor Yellow   
15.     Write-Host "Your Expiration Time in days: " -nonewline; Write-Host $expirationDays -ForegroundColor Yellow   
16.     Write-Host "..."  
17.     $continue = Read-Host "Please confirm your input (y/n)"  
18.   
19.     if($continue -eq "y")   
20.     {   
21.         $webapp = Get-SPWebApplication -Identity $webAppUrl   
22.         $DBName = "WSS_CONTENT_OfficeWebAppsCache_" + $webApp.Name   
23.   
24.         $newDB = New-SPContentDatabase -Name $DBName -WebApplication $webAppUrl -DatabaseServer $DBServer -MaxSiteCount 1 -WarningSiteCount 0   
25.         Write-Host "New Content DB " -nonewline; Write-Host $DBname -ForegroundColor Yellow -NoNewline; Write-Host " created for Web Application " -nonewline; Write-Host $webapp.Name -ForegroundColor Yellow -NoNewline; Write-Host " on Database Server " -nonewline; Write-Host $DBServer -ForegroundColor Yellow -NoNewline; Write-Host "..."  
26.         Get-SPOfficeWebAppsCache -WebApplication $webAppUrl | Move-SPSite -DestinationDatabase $newDB   
27.         Write-Host "Move Office WebApps Cache Site Collection successfully to new ContentDB..."  
28.         $GBSizeInBytes = 1024 * 1024 * 1024 * $CacheSize   
29.         Get-SPWebApplication | Set-SPOfficeWebAppsCache -ExpirationPeriodInDays $expirationDays -MaxSizeInBytes $GBSizeInBytes   
30.         Write-Host "Cache Byte Limit is set to " -nonewline; Write-Host $GBSizeInBytes -ForegroundColor Yellow -NoNewline; Write-Host " and Expiration Time to " -nonewline; Write-Host $expirationDays -ForegroundColor Yellow -NoNewline; Write-Host " days..."  
31.         Write-Host "Operation completed successfully..." -ForegroundColor Green   
32.     }   
33.     else  
34.     {   
35.         Write-Host "The operation was chanceled by user input..." -ForegroundColor Red   
36.     }   

Greift zu und speichert das Skript einfach als PS1 Datei ab. Aufrufen könnt Ihr es dann in der PowerShell mit dem Befehl C:\<Pfad>\<Dateiname>.ps1 .


Hoffentlich hilfts :-)

Good luck,

Andreas

SharePoint 2010 WarmUp Script

In der 2007er Version von SharePoint war ein WarmUp Skript für SharePoint, zum Beispiel dieses von Joel Oleson, Standard. Denn schon damals hatte es der IIS 6.0 an sich, die Webanwendungen Nachts zu recyclen und somit den Cache zu leeren. Der erste Seitenaufruf einer SharePoint-Seite ist nach dem leeren des Caches sehr langsam. Diese Problemstellung hat sich in Zeiten von IIS 7.5 und SharePoint 2010 nicht geändert. Nun gibt es ja für den IIS 7.5 WarmUp Plugin, für dessen Uninstall ich auch schon einen Blogpost geschrieben habe :-)
Die große Preisfrage ist: Was hab ich getan, nachdem das Plugin weg war? Ganz einfach, ich habe ein PowerShell Skript geschrieben, das durch jedes Web iteriert und über eine Webrequest jede Seite einmal aufruft. Das Skript wird durch eine geplante Windows Aufgabe von einem SharePoint Server ausgeführt.
Eine einfache Version eines solchen Skripts sieht folgendermaßen aus:

1. Add-PsSnapin Microsoft.SharePoint.PowerShell -erroraction silentlycontinue  
2.   
3.  foreach ($webApp in get-SPWebApplication)  
4.     {      
5.         foreach ($site in $webApp.Sites)  
6.         {  
7.             foreach ($web in get-SPWeb -site $site)  
8.             {  
9.                 $request = [System.Net.WebRequest]::Create($web.URL)  
10.                 $request.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials  
11.                 $request.proxy = [System.Net.WebRequest]::DefaultWebProxy  
12.                 $request.ContentType = "application/x-www-form-urlencoded"  
13.                 $request.Method = "GET"  
14.         try{  
15.                     $request.GetResponse().StatusCode  
16.             WRITE-HOST $request.GetResponse().StatusCode  
17.                 }  
18.                 catch [Net.WebException]{  
19.                     $WebExceptionMessage = $_.Exception.Message  
20.                     WRITE-HOST "Folgender Fehler ist aufgetreteb: " + $WebExceptionMessage  
21.                 }  
22.             }  
23.         }  
24.     }  

Im Gegensatz zu den Skripts, die ich beim meiner ersten Suche gefunden habe ist das oben erfrischend simpel und lädt zur phantasievollen Weiterentwicklung ein. Wer das ganze eher pragmatisch angeht, kopiert einfach den Code oben in eine Textdatei, speichert diese mit der Endung "ps1" und führt diese ps1 als Aktion im geplanten Windows Tasks einmal die Nacht nach zwei Uhr morgens aus. Beachtet dabei, dass das Skript nur auf einem SharePoint Server ausgeführt werden kann.

Good luck,

Andreas

IIS 7.5 Application Warm-Up Uninstall

Für IIS 7.5 findet man hier ein nettes WarmUp Tool:  Download IIS 7.5 Application Warm-Up . Dieses Tool ermöglicht es einem Administrator, den ersten Benutzer am frühen Morgen nach dem nächtlichen Application Recycle des IIS trotzdem eine angenehm schnelle SharePoint Erfahrung zu ermöglichen. Zu den alten IIS 6.0 und SharePoint 2007 Zeiten hatte man noch Skripts eingesetzt, um nach einem Reset des IIS die SharePoint-Seiten einmal in den Cache zu laden. Das IIS Tool aus dem Hause Microsoft ermöglicht nun eine Konfiguration über die IIS Manager Oberfläche. Man findet zahlreiche gute Blog-Einträge die das Vorgehen hierzu beschreiben, zum Beispiel hier.

Das Einrichten ist denkbar einfach, ebenso die Deinstallation des Tools. Leider ist die Konfiguration auch nach der Deinstallation noch in der web.config der SharePoint-Webanwendungen. Zur Freude eines jeden SharePoint Admins führt eine invalide web.config von SharePoint bei jedem Seitenaufruf zu folgendem Fehler:

HTTP Error 500.19 - Internal Server ErrorThe requested page cannot be accessed because the related configuration data for the page is invalid.Detailed Error Information

Um den Fehler zu beseitigen, muss man jede web.config von Hand anpassen und den Knoten "httpWarmup" in jeder web.config suchen und entfernen. 

Good luck,

Andreas 

Connect to Office - the easiest way to work with documents!

Hi,

today I've teached my students about the "Connect to Office"- Button in the SharePoint 2010. I don't know any student how is not sold on this button - and they are all right! This button is one of the best buttons you can use in SharePoint! OK, before I told you why, i told you how it works.
 You have a document library with several Content Types, two Word Documents and an Excel Sheet.

Fine, and know you push THE button. Choose "Add to SharePoint Sites" under "Connect to Office" in the Ribbon toolbar.

Confirm the dialog box following on your click and open your local Word or Excel and choose "New" like the way you do for creating a Document outside of SharePoint. You would found a new category " templates" with the document library you added before in SharePoint.

Click on it and you see the Content Types from the library in word. Of course, you'll found the Excel Sheet Content Type in your local Excel Client.

To open the Content Type now in Word isn't differently to open it from SharePoint. You can use custom templates as well as the Server Document Properties. And the default Save Location is the SharePoint Library, not your local Filesystem.

As you see- this is the way you can take SharePoint Content Types to your local Word with all the custom templates and Document Properties and all of this stuff. And -yes -, the Content Types works offline- even if the Save Location isn't SharePoint, of course!

But the best argument for this feature is, that this feature makes the handling with documents really more easy. Without a connect to a SharePoint Site, the user has two option:

1. The user starts his Word Client, create a document, search a location (SharePoint or FileSystem) and load the Document to this location,
2. or the user search the location in SharePoint and create his document at this position.

With the connect, the user don't have to search a location...

Regards,

Andreas

Nintex Workflow 2010: User access control - set permissions for allowed actions

In Nintex Workflow 2010 it is pretty simple to set permission for allowed actions, a good way to personalize the actions a designer can use. OK, to restrict the access to workflow actions, you can uncheck the action in the "Manage allowed actions" menu at Central Administration or Site Collection level, too. Do this, and no one will publish or use a workflow with the unchecked action furthermore. And I mean really no one, uncheck a action is not mapped to specific users or groups. Further, Nintex is clever and detect this unchecked actions in User defined actions (UDA) and a workflow with a UDA containing a unchecked action can't be published. Now, if you want restrict the access for "Call a Webservice" or a "Execute SQL" actions for a specific workflow designer group, but also want all other workflow designers to use UDAs containing such actions preconfigured, you have to manage the permissions in the Central Administration. This settings you only can do in the Central Administration, not on the Site Collection or Site Level. OK, to set permissions, go to the Central Administration and clicking "Managed allowed actions" under the "Nintex Workflow Management" header.

 Select the action you want configure and click on "Edit permissions" at the Ribbon.  Now you have the possibility to uncheck the "Make this actions available for all users" check box and change the users or groups with rights on this action.

In my case, I only allow "sps_admin_ak" to configure the "Call a Webservice" action. The user "sps_admin_ak" configure a UDA ( View this post about UDAs ) with the "Call a Webservice" action, for example to set user permissions on a SharePoint list or web. In the next step, any other workflow designer use this UDA in a workflow.

At least, the workflow designer will be able to publish the workflow with the UDA containing the "Call a webservice". He wont be able to use the "Call a Webservice" directly, but can use it preconfigured in a UDA.

Makes sense, I like it :-)

Nintex Workflow 2010: Introduction to User Defined Actions

Hi,

one of the new features in Nintex Workflow 2010 are "User Defined Actions", shortly UDA. Maybe you guess, that a user can define own actions with this new feature - and you are right! A user can build a Workflow in the Workflow designer and save the Workflow as a UDA. Sounds pretty similar to Snippets which is already a feature in Nintex Workflow 2007. The diffrent between Snippets and UDAs is, that UDA is a "black box" with input and output parameters. If a user use a UDA, he can't change the UDA's configuration. OK, now let's have a look how to build a UDA in Nintex Workflow 2010. You can find the UDA Management in the Site Actions menu.

Of course, you can find the UDA Management in the Site Settings, Site Collection Settings and Central Administration, too. In the UDA management, you have several options.

You can create, modify or delete UDAs, import from a Workflow file, export, promote and analyze them. What we want to do is to create a new one. If you click at the Create Button, the Nintex Workflow Designer is opening. The first thing we have to do is to define parameters for the UDA. This are the parameters, a user using our UDA can configure in the Action Configuration. You can find the parameter settings at the "UDA settings" in the Workflow designer Ribbon.

I defined two input parameters for a SiteURL and for a Person or Group. Now I'm ready to build my Workflow. I can use the parameters like variables.

I designed a worklow which is setting user permissions on a SharePoint Site, using the SharePoint WebServices and depending on the input parameters. Finally, I published the Workflow in the usual way. Now, the UDA can be used in other Workflows.

Other Workflow Designers now only have to put this UDA to a Workflow and configure the input parameters to setup User permissions to another site in a Workflow easily.

At my opinion, the UDA feature is one of the  best new features in Nintex Workflow 2010, because it offers the possibility to make the already user friendly Workflow Designer even more friendly for Power Users or Business Users.

Have fun,

Andreas

Nintex Workflow 2010 released!

Nintex released Nintex Workflow 2010, the follower of Nintex Workflow 2007! Nintex offers with the 2010 product release a new version of their liked workflow engine built in SharePoint 2010. Some of the key features of the new version are:

• Sharepoint 2010 like Ribbon interface,
• New SharePoint 2010 features like "Site Workflows",
• Integration in Infopath, Excel Services and Business Integration services,
• Integration to Microsoft CRM,
• User defined actions,
• Print View,
• ...

Find more about Nintex Workflow 2010 at the product page.

Regards,

Andreas