Wer kennt noch die SharePoint-2007-Backup-and-Recovery-Oberfläche der Zentraladministration?

Ohne Umschweife konnte jeder sofort erkennen „Alles klar, das wird dazugekauft“.

Eine ziemlich ernüchternde Angelegenheit.

Mit dem neuen SharePoint Server 2010 und mit Unterstützung von entsprechenden Cmdlets für die PowerShell-Konsole geht das Sichern und Wiederherstellen der Farm oder auch von Teilaspekten davon für den Einsteiger und Fortgeschrittenen gut von der Hand.

Das erste Service Pack für SharePoint behebt Fehler und adressiert gleichzeitig lang ersehnte Funktionalitäten.

Beispielsweise landet eine gelöschte Website zuerst im Papierkorb und kann durch den Endanwender wieder geholt werden, früher musste man bei der IT-Abteilung vorstellig werden und dann auch noch genau erklären, wie es dazu kam.

Microsoft Visio ist ein nützliches Werkzeug, um Abläufe, Prozesse, Statistiken oder IT Landschaften visuell darzustellen.

Solche Zeichnungen schmücken die Wände so mancher IT Büros.

Immer häufiger wandern diese Visio Zeichnungen – meist umgewandelt als Grafik und eingebettet in eine HTML-Seite, ins Intra- oder Extranet.

Alles schön und gut, aber in Microsoft Visio steckt noch viel mehr – Wir sind erst am Anfang einer neuen spannenden Geschichte.

Microsoft hat mit dem SharePoint-Server-2010-Release die Messlatte noch einmal nach oben gesetzt.

Schon in der Beta 2 konnte vieles angesehen und getestet werden.

Fast alle Funktionen liefen fehlerfrei. Die Erfahrungen von Partnern, Testern und früh eingebundenen Kunden haben dazu beigetragen, dass dieses Produkt in Sachen Bedienbarkeit und Funktionalität große Schritte gemacht hat.

SharePoint Server 2010 und Access 2010 stehen mit vielen Neuerungen vor der Tür.

Bei der Planung von neuen Projekten sollte man sich schon jetzt mit ihnen beschäftigen, denn es lohnt sich.

Viele neue Erkenntnisse und Verbesserungen wurden umgesetzt, und eine der interessantesten Neuerungen sind die Access Services.

Wann immer Informationen zusammenfließt und geografisch verteilte Mitarbeiter an einer Sache arbeiten, wandern relevante Informationen hin und her.

Wir sind es mittlerweile gewohnt, bequem und schnell an unsere Daten zu gelangen, aber welche Rolle spielt dabei das Thema Sicherheit?

Was ist diesbezüglich mit SharePoint möglich, und ist Office 365 eine Option?

Viele alte und neu hinzugekommene SharePoint Entwickler beschäftigen sich mit dem Thema SharePoint 2013 und haben wahrscheinlich schon versucht mit Visual Studio 2012 sich dem Thema zu nähern.

Leider ist das nicht so einfach, da nach der Installation beider Software Produkte, SharePoint 2013 und Visual Studio 2012, in letzterem die SharePoint 2013 Projektvorlagen fehlen und alle SharePoint 2010 Projektvorlagen keine Kompatibilität mit SharePoint 2010 aufweisen – ein Hinweis, dass eine SharePoint 2010 Installation vorausgesetzt wird, vereitelt jeden Versuch.

Um jetzt schon erfolgreich für SharePoint 2013 zu entwickeln, müssen ein paar Komponenten installiert werden. Ich gehe erst einmal davon aus, dass der Server über keine Internet Verbindung verfügt.

Bei der Installation der Komponenten ist die Reihenfolge zu beachten

• Windows Identity Foundation SDK
• Windows Identity Extensions
• SharePoint Client Components
• Workflow Tools 1.0 Beta for Visual Studio 2012
• Workflow Client 1.0 Beta
• Microsoft SharePoint Developer Tools for Visual Studio 2012 Preview
• Nur für Visual Studio 2012 RC, July Update

Nachdem alle Komponenten installiert wurden, kann nun jeder nach Belieben die jeweils passende Visual Studio 2012 Projektvorlage wählen.

Für diejenigen, deren Server ans Internet angebunden ist, gibt es den Web Platform Installer 4.0. http://www.microsoft.com/web/downloads/platform.aspx.

Nach dem Download und dessen Start suchti hr nach office <enter> und wält Microsoft Office Developer Tools for Visual Studio 2012 RTM – Preview aus. Alle benötigen Komponenten werden nun mitinstalliert – wie langweilig

Nachdem ein Domänen Benutzer im Active-Directory umbenannt oder dieser in eine andere Domäne migriert wurde, muss man als SharePoint Administrator das Kommando stsadm -o migrateuser oder Move-SPUser ausführen, damit das neue/migrierte Konto die SharePoint Berechtigungen erhält.

Hier ist die Snytax für das veraltete stsadm.exe Kommando

stsadm -o migrateuser -oldlogin -newlogin [-ignoresidhistory] stsadm -o migrateuser -oldlogin HSD\Bob1 -newlogin HS\Bob

Hier ist die entsprechende Syntax für den selben Vorgang, nur mit dem PowerShell Cmdlet und ensprechender Syntax

Move-SPUser [-Identity] -NewAlias [-AssignmentCollection ] [-Confirm []] [-IgnoreSID ] [-WhatIf []]
Move-SPUser -Identity “HSD\Bob1″ -NewAlias “HS\Bob”

Wann immer die Fehlermeldung – DS_NAME_ERROR_DOMAIN_ONLY auftaucht, liegt es daran, das der SidHistory check fehlschlägt.

Das Kommando migrateuser/Move-SPUser sucht in der SIDHistory des neuen Accounts den alten Account (Neuer Account->Prüfe ob es einen Eintrag gibt->OLDName->NEWName)

In folgenden Fällen wird das Kommando Fehlschlagen, da kein Eintrag in der SID Historie des neuen Accounts gefunden werden kann.

• Der Benutzeraccount wurde nicht umbenannt, sondern neu erstellt
• Der Benutzeraacount wurde in eine andere Domain transferiert

Im ULS sieht die Meldung dann wie folgt aus:

stsadm: An error occurred while translating user name ‘HS\BOB1′ to a Windows account name – (DS_NAME_ERROR_DOMAIN_ONLY) Callstack: at Microsoft.Office.Server.Utilities.WindowsSecurity.TranslateUserName(String name, DS_NAME_FORMAT formatOffered, DS_NAME_FORMAT formatDesired) at Microsoft.Office.Server.UserProfiles.Helpers.GetSidHistory(String strAccountName) at Microsoft.Office.Server.UserProfiles.Helpers.IsSidInSidHistory(String strAccountName, Byte[] bOldSid) at Microsoft.Office.Server.Administration.AccountMigrationManager.MigrateAccount(Guid partitionId, UserProfileApplication userProfileApplication, String strOldAccountName, String strNewAccountName, Boolean bEnforceSidHistory)

Lösung

Glücklicherweise gibt es einen Schalter, der den SidHistory check umgeht.

• stsadm -o migrateuser -oldlogin HSD\Bob1 -newlogin HS\Bob -ignoresidhistory
  
• Move-SPUser -Identity “HSD\Bob1″ -NewAlias “HS\Bob” -ignoresidhistory

——————-Update vom 10.11.2012————————

Pünktlich zur SharePoint Konferenz 2012 in Las Vegas wurde der Windows PowerShell for SharePoint Command Builder mit neuen Funktionen aufgefrischt

In der Produktauswahl stehen uns jetzt  Cmldlets für SharePoint 2013 zur Verfügung.

Besonders hilfreich sind in meinen Augen die Quick Steps.

Die Quick Steps sind die Geläufigsten Befehlskombinationen, die wir bei der täglichen Arbeit verwenden.

Folgende Quick Steps stehen zur Verfügung:

• Activate a feature across all sites for a Web application
• Create a site
• Move all sites from one content database to another
• Create a site in a specific content database
• Backup a site
• Delete a site
• Return all Webs in all Sites
• Add a user to a domain.group
• Remove a user from a domain-group
• Delete a Content Database

———————————–End Update —————————————-

Die PowerShell ist für SharePoint 2010 und/oder Office 365 Administratoren eines der mächtigsten und beliebtesten Werkzeuge.

Leider besteht die Herausforderung allein schon darin, die vielen Cmdlets mitsamt den richtigen Parametern in Verbindung zu bringen, geschweige denn alle Verb-nomen Kombinationen im Kopf zu behalten.

Es gibt ein super Online Werkzeug, dass uns genau darin unterstützt. Es nennt sich Windows PowerShell Command Builder.

Mit dem Windows PowerShell Command Builder kann man sich seine Kommandos per Drag & Drop zurechtlegen und je nach Kommando haben wir die Möglichkeit erforderliche oder optionale Parameter einzugeben.

Am Ende erhalten wir das Kommando mitsamt TechNet link zur weiteren Recherche.

Problem

Beim arbeiten mit InfoPath 2010 und SharePoint 2010 ist mir folgende Meldung über den weg gelaufen.

“This InfoPath form template is browser-compatible, but it cannot be browser-enabled on the selected site” Dies Formular lies sich zwar veröffentlichen, jedoch aber nicht danach im Browser öffnen – jedes mal öffnete sich die Client Anwendung. Tests haben gezeigt, dass dieses Problem nur eine bestimmte SiteCollection betraf.

Lösung 1

Da wir eine Enterprise Funktionalität verwenden, ist es notwendig die endsprechenden Features zu aktivieren

• SharePoint Server Enterprise Site Collection features
• SharePoint Server Enterprise Site features

Lösung 2

In bestimmten Umgebungen kann es sinn machen, per default festzulegen, dass Office Dokumente im jeweils dafür vorgesehenen Client angesehen werden und nicht im Browser, hierfür gibt es ein Feature welches dieses Verhalten steuert.

Gemeint ist das Webseitensammlungsfeature – Open Documents in Client Applications by Default. Zusätzlich gibt es noch ein Schalter der dieses Verhalten per Dokumentenbibliothek steuert (Opening Documents in the Browser).

Lösung 3

Haben sie alles korrekt konfiguriert? Tritt dennoch auf? Probieren sie es mit folgenden Kommano – entweder über die PowerShell Cmdlets oder per STSADM-Befehl.

• Enable-SPFeature IPFSWebFeatures –Url http://meinefarm/meinesite
   
• STSADM.EXE -o activatefeature -filename IPFSWebFeatures\feature.xml -url http://meinefarm/meinesite -force