Dienstag, 15. März 2011

Claims Based Authentication, IIS 401 und Access Denied.

Claims Based Authentication ( CBA ) - Authentifizierung der nächsten Dimension, neu, toll und das beste: es gibt keinen Grund es NICHT zu tun!!! Sagt zumindest Microsoft, ich zitiere:
There are no additional steps to implement Windows authentication when you use the claims-based authentication mode.
So Stand es zumindest zum Veröffentlichung-Datum dieses Artikels auf TechNet geschrieben. Leider muss diese Prophezeiung erst noch in Erfüllung gehen. Ich wurde die letzten Tage doch ziemlich arg von der CBA gebeutelt. Ich brauche Forms zur Anmeldung, das funktioniert nur mit CBA. Was tun, wenn die CBA Windows integriert nicht funktioniert?
Die Problemstellung ist, das Benutzer vom IIS einen HTTP Fehler 401 bekommen, wenn Sie auf SharePoint zugreifen. Access Denied vom IIS, nicht vom SharePoint. Zugreifen können Benutzer das Portal über verschiedene URLs, http://1111, https://1111,  http://1111.domain.local usw. und so fort. Mein Alternate Access Mapping sah dabei wie folgt aus:
Jede URL ist in einer eigenen Zone. Nachstellen konnte ich, dass die Authentifizierung immer nur über eine dieser URLs funktioniert hat, und zwar:
  • Für jeden Nutzer die gleiche URL,
  • Bis zum nächsten IIS Reset, 
  • Nach einem IIS Reset funktioniert der Zugriff über eine zufällige URL.
 Nach Stunden des Troubleshootings habe ich folgendes Alternate Access Mapping ausgetestet:
  Alle URLs sind auf eine Zone eingetragen ( "Add Internal URLs" ). Und siehe da, die Authentifizierung funktioniert über jede URL! Da in der Zwischenzeit der Microsoft Support eingeschaltet war und das Problem nicht kannte/ lösen konnte, bleibt mir nur der Schluss: Es ist ein Bug, eine Windows Authentifizierung mit CBA, die einen Zonen-Wechsel nicht verkraftet kann nicht "Work as designed" sein! Das waren meine Rahmenbedingungen:
  • Es handelt sich um eine SharePoint Farm, allerdings nur ein Web Frontend Server,
  • Stand CU Dezember 2010,
  • Classic Authentifizierung funktionierte ohne Probleme,
  • Problem trat sowohl bei NTLM als auch bei Kerberos auf
Für meine Lösung reicht der "Workaround" aus dem zweiten Screenshot, zumindest in diesem Fall. Mehr Zeit möchte ich auch nicht in weiteres Troubleshooting zum weiteren Eingrenzen des Problems investieren. Sollte ein kommendes CU den Fehler beheben, werde ich es vermerken. Sollte jemand von euch weitere Infos zu diesem Problem haben, freue ich mich über jedes Kommentar. Falls nicht hoffe ich, dass ich dem ein oder anderen wenigsten einige Stunden Troubleshooting ersparen kann!

Good Luck,

Andreas

Samstag, 19. Februar 2011

User Properties mit PowerShell anlegen und bearbeiten

Aus der Not geboren ( Die Not hat den Namen "CU December" und ich habe mich in diesem Post schon darüber ausgeheult :-) ) habe ich mich damit beschäftigt, wie man denn eigene User Properties in User Profiles automatisch befüllen und erstellen kann. Als Nicht- Developer und Admin denke ich dabei natürlich immer zuerst an die PowerShell! Dumm nur dass Microsoft offensichtlich vergessen hat uns dafür die nötigen Befehle direkt für die PowerShell einzupacken. Seltsam, da sich sicher jeder, der schon einmal die überwältigend träge, hässliche, langsame und undhandliche Maske zum administrieren der User Properties in SharePoint noch nie sehnlicher ein Power Shell- Skript gewünscht hat.
User Property Administration - ein Administrations-Alptraum wie aus den frühen 90ern.

Wir müssen uns des Objektmodells bedienen, um diese Eigenschaften über die PowerShell verwalten zu können. Die benötigte Klasse hierfür ist UserProfilManager ( http://msdn.microsoft.com/en-us/library/microsoft.office.server.userprofiles.userprofilemanager.aspx ).
Bauen wir uns also ein Skript, beginnen wir mit dem laden der SharePoint cmdlets und dem erstellen eines UserProfileManager-Objekts. Dieses Objekt beinhaltet alle Profile und Properties aus der Service Application, die im Kontext der angegebenen Seite verwendet wird.

  1. # Load Sharepoint SnapIn      
  2. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)      
  3. {      
  4.     Add-PSSnapin Microsoft.SharePoint.PowerShell      
  5. }     
  6.     
  7. # Create Service Context      
  8. $site = Get-SPSite http://mySiteHostUrl      
  9. $serviceContext = Get-SPServiceContext $site     
  10.     
  11. # Get ProfileManager, User Profiles and User Properties      
  12. $profileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($serviceContext)      
  13. $userProfiles = $profileManager.GetEnumerator()      
  14. $properties = $profileManager.get_Properties()   
Nun haben wir eigentlich alles was wir dazu benötigen, neue User Properties anzulegen und bestehende Profile zu befüllen. Neue User Properties kann man wie folgt anlegen:
  1. # Create new Property   
  2. [Microsoft.Office.Server.UserProfiles.Property]$property = $properties.Create($false)   
  3. # Set property vaules   
  4. $property.set_Name("Property Name")   
  5. $property.set_Description("Property Description")   
  6. $property.set_DisplayName("Property Displayname")   
  7. $property.set_IsUserEditable($true)   
  8. $property.set_IsVisibleOnEditor($true)   
  9. $property.set_IsVisibleOnViewer($true)   
  10. $property.set_Type(String)   
  11. $property.set_Length(255)   
  12. # set other values you need...   
  13. $property.Commit()   
  14. # Add new Property to Repository   
  15. $properties.Add($property)  
Denkbar einfach, so eine property anzulegen, wenn man erstmal ein ProfileManagerObjekt hat. Das wichtigste hierbei ist eigentlich, den richtigen Typ ( set_Type() ) zu wählen ( String, Multi Value, etc...). Fast noch einfacher ist es dann, das User Property für jedes Profil befüllen zu lassen.

  1. foreach($userProfile in $userProfiles)   
  2. {   
  3.     # Set New Value   
  4.     $userProfile["Property Name"].Add("New Value")   
  5.     $userProfile.Commit()   
  6. }  
Ein solches Skript, vielleicht noch ein geplanter Windows Task und dazu die nötige Phantasie sollten eigentlich eine nützliche Lösung ergeben können :-) Viel Spaß damit!

Good luck,

Andreas


Mittwoch, 16. Februar 2011

CU Dezember, NetBiosEnabled, User Profile Sync und MIISRCW: System.NullReferenceExeption <- Neue Erkenntnisse

SOLVED WITH
CU FEBRURARY 20100



Na, NetBiosName unterschiedlich vom FQDN? Benutzerprofilsynchronisations-Dienstanwendung für den Import des NetBios Names aktiviert? Aktuell CU December installiert? Neue Import Connection notwendig? Pech gehabt! :-) Seit CU December dankt SharePoint das mit der Meldung Unable to process Create message ( oder Unable to process Put message wenn man versucht, eine bestehende Verbindung zu ändern ). Im Event Log sieht man dann eine Event ID 3:


ERROR:
"Unable to process create message"
EVENT LOG:
Forefront Identity Manager: Event ID 3
----------------------------------------------
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri}
MIISRCW: System.NullReferenceException: Object reference not set to an instance of an object.
   at MIISRCW.IMMSMAUtility.UIGetData(String pszRequestInformation, Int32& pfSuccess, String& ppszResult)
   at Microsoft.ResourceManagement.SyncConfig.TryGetSchema(String maType, String initializationString, String& returnString)
   at Microsoft.ResourceManagement.ActionProcessor.SyncConfigActionProcessor.Create(String typeName, IList`1 createParameters, Guid creator, Guid cause)
   at Microsoft.ResourceManagement.ActionProcessor.SyncConfigActionProcessor.ProcessInputRequest(RequestType request)
   at Microsoft.ResourceManagement.ActionProcessor.ActionDispatcher.ProcessInputRequest(RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction(RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction[ResponseBodyType](RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request, Guid requestIdentifier, Object redispatchSingleInstanceKey)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request)
   at Microsoft.ResourceManagement.WebServices.ResourceManagementService.Create(Message request)
Na, da bleibt wohl nur das hoffen auf das nächste CU oder SP ( lt. diesem Forenverlauf stehts sogar seit 14. Februar auf der Liste von MS http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/e08b9564-05c0-4791-b8a2-e589834c4b7c ). Obwohl, langsam schleicht sich so ein unangenehmes Gefühl beim einspielen ein....

Good luck und immer auf dem neusten Patch-Level bleiben, höhöhö,


Andreas


P.S.: Wer nun wegen Terminen doch ne schnelle Lösung braucht: Wenn man den Account Name im Profil manuell ändert, wird er beim inkrementellen Import nicht mehr geändert...

Donnerstag, 3. Februar 2011

Duet Enterprise for SharePoint and SAP

Vorbei ist er - der Virtual Launch Event zu Duet Enterprise for SharePoint und SAP am 01. Februar 2010! Dabei sollte keiner, der sich schon den Kopf über SAP und SharePoint in der gleichen Problemstellung zerbrochen hat, sich voraussichtlich noch zerbrechen wird oder sich den Kopf von anderen Leuten darüber zerbrechen wird, dieses Event verpaßt haben. Ups, doch verpaßt? :-) Nicht schlimm, schnell hier anschauen:

http://www.duetenterprisesummit.com/SitePages/Agenda.aspx

Noch nie etwas von Duet Enterprise gehört? Das ist schnell erklärt:

Das, was Duet Enterprise ausmacht ist der Pfeil zwischen SAP NetWeaver und SharePoint. Der verbindet nämlich das Duet Enterprise SAP Add-on mit dem Duet Eterprise SharePoint Add-on. Und das bietet tolle Vorteile für ansonsten Recht interessante Dinge wie:
  • Single Sign On SAP Benutzer und Windows Benutzer,
  • Business Connectivity Services Entitäten OOTB, 
  • ...
 Somit sollte man in der Lage sein, ziemlich schnell sowas wie unten auf dem Bild zu basteln:

SAP HR, Empoyee Self Services in SharePoint? Kein Problem, Duet Enterprise ist ja jetzt mehr Framework als fertige Prozesse aus Duet 3.5 Zeiten... Also, schnell noch den Virtual Launch Event anschauen!

Good luck,

Andreas

Dokumente von Filesystem automatisch nach SharePoint importieren

Hallo zusammen,

anbei ein kleines PowerShell Skript, dass alle Dateien aus einem Ordner des Filesystems in eine SharePoint Liste importiert. Mir hat das Skript schon oft geholfen, ob als Hilfe für Datenmigration oder ob als geplanter Windows Tasks, der frisch eingescannte Dokumente regelmäßig importiert. Natürlich ist es möglich, automatisch Metadaten an die neu nach SharePoint hinzugefügten Dokumente anzufügen oder den Ersteller oder das Erstellungs-Datum vom Filesystem nach SharePoint zu importieren - aber Ihr werdet da schon die nötige Phantasie mitbringen :-)

  1. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)   
  2. {   
  3.     Add-PSSnapin Microsoft.SharePoint.PowerShell   
  4. }   
  5.   
  6. $web = Get-SPWeb -Identity "http://sites/web/" ### Set your web URL   
  7. $folder = $web.GetFolder("http://site/web/list") ### Set your List URL here   
  8.   
  9.     foreach ($file in Get-ChildItem -Path "c:\folderwithdocuments") ### Set the location path of the folder with the documents here   
  10.     {   
  11.         $bytes  = [System.IO.File]::ReadAllBytes($file.Fullname)   
  12.         $SPDoc = $folder.Files.Add($file.Name,$bytes,$true)   
  13.         $SPDoc.Update()   
  14.         WRITE-HOST $file.FullName + " successfully added!" -ForegroundColor Green   
  15.     }   
  16. $web.Dispose()  

Ich hoffe es hilft!

Good luck,

Andreas

Donnerstag, 27. Januar 2011

SharePoint Cumulative Update ( CU ) December

Das CU Dezember für SharePoint 2010 ist nun schon ein paar Wochen verfügbar. Finden tut man das ganze unter der offiziellen Microsoft Seite Updates for SharePoint 2010 Products. Dort kann man sich immer das neuste Material herunterladen. Den Post schreib ich aber nur, um euch auf den folgenden Satz aufmerksam zu machen, der unter dem CU December steht:

Note: You must restart the User Profile Synchronization service after installing this cumulative update. For more information see the Start the User Profile Synchronization service section in the Configure profile synchronization article in the library.

Also nicht vergessen, den Benutzerprofil-Synchronisationsdienst neu zu starten!

Good luck,

Andreas

P.S.: Schon gewußt, dass man den Konfig-Wizard nach der Installation von CUs und SPs nicht mehr nach einander auf jedem Server ausführen muss? Einfach
psconfig –cmd upgrade –inplace b2b -wait
auf jedem Server in der Kommando-Zeile aufrufen!

Mittwoch, 26. Januar 2011

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