Freitag, 3. Juni 2011

Nintex Live - Nintex Workflow aus der Wolke

Es ist wieder so weit - Nintex hat ein neues Spielzeug für uns! Nintex hat die Trends erkannt und uns etwas für die Wolke gebastelt - Nintex Live! Alle, die schon Nintex Workflow 2010 einsetzen, können nun verschiedene Dienste von Nintex und Partnern aus der Wolke konsumieren. Die auf Windows Azure implementierte Lösung stellt einen Katalog an Diensten bereit, die wie die schon bekannten Aktionen im Workflow Designer eingesetzt werden können. Letztendlich sind aber alle Aktionen nur Webservices, die durch die Aktion aufgerufen werden. Webservices bieten dabei Dienste an wie Statusupdates für soziale Netzwerke, Übersetzungen, Kontrolle der Flugdaten oder aber auch die Übergabe von Daten an einen Workflow in einer anderen Farm. Die folgende Darstellung verdeutlicht die hinterlegte Infrastruktur:
Da Partner den Nintex Live Katalog erweitern werden, wird es sich lohnen http://www.nintex.com/en-US/Products/Pages/NintexLive.aspx genauer anzuschauen!

Good luck,

Andreas

Samstag, 28. Mai 2011

SharePoint Alternate Access Mapping URL Redirect

Hi,

AAM ( Alternate Access Mapping - Alternative Zugriffszuordnung ) URL Redirect ist ein interessantes Feature im SharePoint 2010, der eine Migration von SharePoint 2007 auf 2010 vor sich hat, die sich unter Umständen über einen längeren Zeitraum hinzieht. AAM URL Redirect wird immer dann interessant, wenn die neue SharePoint 2010 Farm die gleiche URL wie die alte 2007 Farm verwenden soll.
Häufiges Beispiel: http://intranet.company.com ist die produktiv 2007er Farm, die URL soll aber nach der Migration von der neuen 2010er Farm verwendet werden, es werden aber nicht alle Inhalt gleichzeitig migriert sondern Stück für Stück. Zwei Systeme und eine URL sind nur schwierig möglich und ein supportetes Szenario fällt mir für SharePoint nicht ein, auch wenn ich darüber noch nicht wirklich nachgedacht habe :-) Also bekommt das alte System eine andere URL - aber was ist dann mit den gespeicherten Links der Anwender in den Browserfavoriten, Emails etc...?
AAM Rerouting deckt dieses Szenario ab, indem man das neuen SharePoint 2010 System so konfiguriert, dass es Inhalte, die es selbst nicht beinhaltet und finden kann, unter einer anderen URL auf einem SharePoint 2007 System sucht.
http://technet.microsoft.com/en-us/library/ee720448.aspx stellt eine Doku zu AAM URL Redirect bereit, aber für Lesefaule hier eine kurze Zusammenfassung und den ein oder anderen Tipp, den man sich dort nicht anlesen kann. Folgendes Szeanrio:
Um dieses Szenario mit AAM URL Redirect umzusetzen, muss man eigentlich nur folgende Schritte tun:
  1. Sobald das neue System verfügbar ist und erreichbar, ändert man zuerst die internen DNS Einträge, so dass http://intranet.company.com auf den neuen Server zeigt und http://old-intranet.company.com auf den alten Server.
  2. Man ändert auf beiden Systemen - neu und alt - wie gewohnt die Einstellungen für alternative Zugriffszuordnung.
  3. Man führt auf dem SharePoint 2010 Server folgenden STSADM Befehl aus:

STSADM.EXE  -o  addzoneurl  -url  http://intranet.company.com  -urlzone  Default  -zonemappedurl  http://intranet.company.com  -redirectionurl  http://old-intranet.company.com

Fertig! So einfach ist das! Am STSADM Befehl kann man erkennen, dass man für eine öffentliche URL im neuen SharePoint Portal einfach eine RedirectionUrl angeben soll. Falls man für eine Webanwendung mehrere öffentliche URLs konfiguriert hat, muss man den Befehl entsprechend oft und mit entsprechend geänderten Parametern ausführen.

 Was ich bisher wissenswertes über AAM URL Redirect herausfinden konnte ist:
  • Die Inhaltssuche findet in der gemappten Zone des Alt-Systems statt, über alle Inhalte aller Site Collections in der Webanwendung.
  • Es kann nur natürlich nur eine Redirection URL pro öffentlicher URL hinterlegt sein,
  • Managed Paths auf dem alten System müssen auch auf dem neuen System angelegt werden, ansonsten funktioniert der Redirect nicht.
  • Es muss sich nicht tatsächlich migrierten Inhalt handeln, der durch ein Migrationsverfahren ( Migration API oder Content Database Attach ) vom alten auf das neue System transportiert wurde, damit ein Redirect erfolgreich ist.
Falls ich noch was neues zum Thema AAM URL Redirect dazulernen darf, erweitere ich die Liste.

Bis dahin:

Good luck,

Andreas

Dienstag, 19. April 2011

Suchergebnisseite mit PowerShell setzen

Hi,

Websitesammlungen mit der PowerShell Scripts anzulegen ist eine gute Angewohnheit. Viele Einstellungen kann man nur oder am besten mit der PowerShell konfigurieren, so zum Beispiel die Inhaltsdatenbank oder das Taxonomy Feature. Meistens sind das Konfigurationen, die man für jede Websitesammlung konfigurieren möchte. Auch die Zielergebnisseite ist eine solche Einstellung, hat man doch in vielen Fällen ein, oft unter hohem Aufwand angepasstes, Suchcenter. Manuell kann man diese Einstellung in den Websiteeinstellungen unter "Sucheinstellungen" konfigurieren.
 Diese Einstellungen ist eine Property im SPWeb Objekt und kann, wie im folgenden Beispielskript, mit der PowerShell gesetzt werden:

  1. $site = Get-SPSite -Identity "http://sitecollection"  
  2. $web = $site.RootWeb   
  3. $web.AllProperties["SRCH_TRAGET_RESULTS_PAGE"] = "/search/customresults.aspx"  
  4. $web.Update()   
  5. $web.dispose()  
Recht einfach also, diese Einstellung in seinen Skripten zu verwendet.
!!ACHTUNG!! Wer sich jetzt überlegt, dass ein SPWeb und seine Properties ja auch alle Subseiten sind und man auf diese Art eigene Ergebnisseiten für Sub-Seiten konfigurieren kann, was über die Oberfläche ja nicht möglich ist, der sollte wissen: JA, man KANN das Property auf jedem Subweb setzten. Interessiert nur den SharePoint nicht, der holt immer das Property vom Rootweb :-)

Good Luck,

Andreas

Donnerstag, 14. April 2011

PDF und MSG Dateien in SharePoint 2010 öffnen - Browser File Handling

Immer wieder werde ich gefragt, wie man in SharePoint 2010 Adobe PDF Dateien denn "richtig" öffnen könne. Also, ohne vorher die Datei erst zu speichern oder ähnliches. Ein beliebtes Thema auf jedem SharePoint-Blog, hat man doch seit der 2010er Version von SharePoint die Möglichkeit, diese Einstellung in der Zentraladministration vorzunehmen. Und vor allem: Man kann mit der gleichen Einstellung auch MSG Dateien ( Outlook ) direkt öffnen. Das wird jeden freuen, der in der 2007er Version von SharePoint schon Outlook MIME Types in die Registry gefummelt hat. Nun Reihe ich mich aber mal brav bei anderen SharePoint Bloggern ein und trage die Kunde des Browser File Handlings in die Welt!
Die Problemstellung schaut wie folgt aus:

SharePoint möchte die Datei speichern oder abbrechen, bietet aber kein Öffnen- Button an. Das ist mit MSG Dateien übrigens das Gleiche. Ändern kann man das Verhalten in der Zentraladministration.Von der Startseite aus geht man auf "Web Applications", markiert die entsprechende Webanwendung und klick "General Settings" oben im Ribbon. In der darauf folgenden Konfiguration ändert man die Einstellung "Browser File Handling" von "Strict" auf "Permissive" um.
Bestätigt man den Dialog, werden PDF-Dateien zukünftig im Browser direkt geöffnet und bei MSG Dateien aus gibt es den "Öffnen" Knopf.
Keine Frage -  man verändert mit diesen Einstellungen die Sicherheitseinstellungen des Servers und lockert diese. Für alle, die das nicht interessiert hab ich noch ein kleines PowerShell Skript, dass die Arbeit für jede Webanwendung automatisch erledigt :-)


  1. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null){   
  2.     Add-PSSnapin Microsoft.SharePoint.PowerShell   
  3. }   
  4.   
  5. foreach($webApp in Get-SPWebApplication){   
  6.     if ($webApp.BrowserFileHandling -eq "Strict") {   
  7.         $webApp.BrowserFileHandling = "Permissive"  
  8.         $webApp.Update()   
  9.     }   
  10. }  

Good luck,

Andreas

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...