Montag, 17. Oktober 2016

Microsoft Identity Manager for SharePoint 2016 Profile Synchronization and possible Errors

Dear SharePointers,

As Microsoft released the new product cycle for SharePoint there was one big change announced: User Profile Synchronization Service is deprecated and not included, only Active Directory Import and an external Identity manager enable SharePoint to get User Profiles.

As we all had our pain points with the User Profile Service regarding Forefront Identity Manager at first everyone seemed to be happy.
Well, at first. What about the need to sychronise Information from Active Directory to SharePoint and vice versa ?
Active Directory Import can't help you with that need.

Because of that and to provide an identity management platform, Microsoft has release the Microsoft Identity Manager (MIM) to achieve that.

So how is this stuff set up ?

First, you have to download the tool here. Please note that this is a evaluation version.

Please also note, that Microsoft Identity Manager should be installed on a box separate from SharePoint. You have the option to install it on SQL or on a remote machine.
In my scenario, I didn't want to install it on a separate machine and installed it on the SharePoint Server.
´
You can follow the wizard as shown in the screenshots.

 As stated above I installed the MIM on the local computer with SQL as the default instance.


Next you have to enter the service account under which the service will run.


Next Some Groups have to be entered.


BOOM - First error. The Groups already have to exist. It would be too much if the setup could create the groups for us ;)


After entering existing groups everything works as designed.





We get the information that the encryption key needs to be stored so we give it a name and save it.


Now the installation is completed.

For reference you can read this article.

As next step we have to start Central Administration and switch the Synchronization Mode from Active Directory Import to External Identity Manager.

This can be done via this path: Application Management -> Manage Service Application -> Click "User Profile Service" -> Configure Synchronization Settings -> Select "External Identity Manager" and Click Ok.

Now we need to download some files to make the Identity Manager work:

- First download the solutions files from here.
  These files contain the information that is needed for the synchronization to work properly.
- Now we need to download following Hotfix Package (KB3092179)
- To make the synchronization work with SharePoint, we also need to download the SharePoint Management Agent (SPMA)

Now we install the Hotfix Package we downloaded in the steps above:
First we extract the package to a folder (in our case C:\DEMO\MIM)





Next we double-click the FIMSyncService_x64_KB3092179.msp to start the installation.




 BOOM - Second Error: We need to stop the Service and retry the Installation.



 After the update has completed, we now have to install the SharePoint Connector to make synchronizing with SharePoint work.





This will complete the installation of Microsoft Identity Manager for User Profile Service in SharePoint 2016. Next, We have to configure the Synchronization for the User Profile Service.

For this task we need the solution files we downloaded.
The purpose of the files is as follows:

We create a directory called C:\SharePointSynchronization and place the solution files there.

In the next step we install the solution files and configure the sync.



For the installation of the Synchronization we modify the above mentionend Powershell Script and save it as Sync.ps1

Install-SharePointSyncConfiguration -Path "C:\SharePointSynchronization" -ForestDnsName spdevdom.local -ForestCredential (Get-Credential spdevdom0\administrator) -OrganizationalUnit 'ou=Users,dc=spdevdom,dc=clocal' -SharePointUrl http://spdev2016:2016 -SharePointCredential (Get-Credential spdevdom0\administrator) –Verbose


First we get the prompt for the account we specified during setup. Enter the proper credentials here.



As the verbose output shows the synchronization seems to be setup correctly. I will come back to the term "seems" shortly.

Now we start the synchronization with the command shown below.

Start-SarePointSync -WhatIf -Verbose

The WhatIf Switch means that the run will only be simulated and not actually executed.



As we can see there are zero updates, adds or deletes.

So something must be wrong here because we expect 22 adds in our environment as this is the initial import.

After a lot of digging around and launching the Synchronization Manager we can see that this is still the Forefront Identity Manager. Hooray, we can still work with this great tool *sigh*

So the solution to this problem is as follows:

1) Open the MIM Client
2) Select "Management Agents" in the top bar
3) Double-Click "ADMA"


In the pop-up, we select "Configure Directory Partitions" from the left navigation.
From there, we select the "DC=spdevdom,DC=local" partition and click on "Containers"


Et voila - We can see that no containers are selected for our domain. So it makes sense that nothing is imported during the run of our script.


For testing purposes I've selected all containers.


We close all open dialogues with OK.
Now we try to run our synchronization again.


Hooray - Now we have our 22 additions.
A look at the Profiles in SharePoint shows all our profiles now.

Hopefully this post can guide you through the not-so-straight-forward process of implementing Microsoft Identity Manager and help you synchronizing your people to SharePoint again.

Best Regards,
Chris

Dienstag, 19. Juli 2016

SharePoint 2016 June 2016 CU Upgrade fails

Liebe Leser,

Wenn man SharePoint einsetzt, möchte man natürlich auch, dass alle Bugs und eventuell ungewünschten Verhaltensweisen behoben werden.
Um dies zu erreichen, ist es sinnvoll, die kumulativen Updates (kurz CU's) für SharePoint zu installieren.

Ich persönlich befolge immer die Regel, ein Update abzuwarten, bevor das vorhergehende Update installiert wird. Der Grund dafür ist, dass Microsoft selten aber doch Updates wieder zurückzieht, da es ungewünschte "Nebenwirkungen" gibt, wenn das Update installiert ist.

Bei der Installation des Juni 2016 Updates und der anschließenden Ausführung des Config Wizards bin ich auf folgenden Fehler in den Logs gestoßen:

"Unable to create a Service Connection Point in the current Active Directory domain. Verify that the SharePoint container exists in the current domain and that you have rights to write to it.
Microsoft.SharePoint.SPException: The object LDAP://CN=Microsoft SharePoint Products,CN=System,DC=mydom,DC=local doesn't exist in the directory.
   at Microsoft.SharePoint.Administration.SPServiceConnectionPoint.Ensure(String serviceBindingInformation)
   at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run()"

Bei der Überprüfung, ob der entsprechende Container existiert, hat sich herausgestellt, dass der Container wirklich nicht vorhanden ist.

Aus diesem Grund habe ich den Container folgendermaßen erstellt:

1) ADSI Edit öffnen
2) Container unter folgendem Pfad anlegen:



3) Regedit aufrufen
4) Key "SharePoint" unter HKLM\SOFTWARE\Policies\Microsoft anlegen

Nach einer Neuerlichen Ausführung des Config Wizards wurde dieser mit der Meldung "Container Distinguished Name Mismatch" abgebrochen.

Dieses Problem wird durch das ausführen des Config Wizards über die SharePoint Admin Shell umgangen / behoben:

"psconfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources"

Eine gute Quelle für die Optionen des psconfig Command-Line Tools ist der Blog von Stefan Gossner.

Nach der Ausführung des Upgrades läuft dieses dann auch fehlerfrei durch.

In diesem Sinne,

Happy SharePointing ;)

Mittwoch, 6. Juli 2016

Nach Backup-SPSite bleibt SiteCollection Read-Only

Liebe Leserinnen und Leser,

Hier wieder einmal ein Highlight der Features von SharePoint:

Angenommen, man möchte eine SiteCollection von einer WebApplication in eine andere verschieben, so ist das lt. Microsoft über die Backup und Restore Funktionalität zu bewerkstelligen.



Gesagt - getan:



Man führt das Powershell-Statement für das Backup aus (hier noch einmal zur Erinnerung)


Backup-SPSite <SiteCollection URL> -Path <Pfad>

Nachdem das Backup durchgelaufen ist, möchte man die SiteCollection dann restoren:



Restore-SPSite <SiteCollection URL NEU> -Path <Pfad des .bak File>

Wie erwartet funktioniert das restoren der SiteCollection reibungslos.

Nachdem der Restore nun abgeschlossen ist, möchte man die alte SiteCollection löschen, da sie ja dort nichts mehr verloren hat.



Hier fängt das Problem nun an und man sieht es sofort, wenn man die Seite ansurft:




Weder das Setzen der Quotas and Locks hat funktioniert (Option zur Aufhebung des Locks ist ausgegraut), noch diverse stsadm-Befehle haben zum Erfolg geführt.
Schlussendlich war es wieder die Powershell, die einen aus dieser misslichen Lage befreit.

SharePoint Management Shell als Administrator starten und folgende Befehle ausführen:
$Admin = new-object Microsoft.SharePoint.Administration.SPSiteAdministration(<SiteCollectionURL>)
$Admin.ClearMaintenanceMode()

Nach dem Ausführen dieser Statements ist die Seite wieder ganz normal erreich- und bearbeitbar.

Grund für dieses Verhalten kann ein unterbrochener Backup-Vorgang sein.

Aus diesem Grund wurde in SharePoint 2013 die Property "MaintenanceMode" eingeführt.
Die Methode zur Aufhebung des Maintenance Modes wurde mit dem April 2013 CU für SharePoint 2013 eingeführt. Es ist daher wichtig, darauf zu achten, dass SharePoint sich mindestens auf Patchlevel April 2013 CU befindet (entspricht Build Number 15.0.4505.1005 für SharePoint Server bzw. 15.0.4505.1002 für SharePoint Foundation)

In diesem Sinne - Happy SharePointing :)

Lg,
Chris



Dienstag, 20. Oktober 2015

SharePoint 2013 August Cumulative Update schlägt bei Installation fehl

Liebe Leser,

Dass SharePoint immer auf dem aktuellen Patchlevel gehalten werden sollte (- 1 Monat, damit das Paket von MS notfalls noch zurückgezogen werden kann ;)) ist kein Geheimnis.

Allerdings kann es bei der Installation des August 2013 CU zu einem Fehler während der Installation kommen.

Das Problem:

Die Installation bricht mit der Meldung "Installation of this package failed." ab.

Durchsucht man dann die Logilfes (C:\Users\<Benutzer>\AppData\Local\Temp\opatchinstall.log), findet sich folgender Fehler:

CAQuietExec:  Error 0x8007000d: CAQuietExec FailedCustomAction RegisterPerfmonManifest returned actual error code 1603 note this may not be 100% accurate if translation happened inside sandbox)

Das Problem hierbei ist, dass das CU somit teilweise installiert wird.

Der Workaround:

Falls dieser Fehler auftreten sollte, muss man das CU noch 2 weitere Male installieren (beim 2. Mal schlägt es auch fehl, beim 3. Mal klappt es - aus welchen Gründen auch immer) und danach den Configuration Wizard ausführen.

Die Lösung:

Für alle, die das August CU noch nicht installiert haben, hat Microsoft das September CU veröffentlicht, das alle Updates seit Service Pack 1 enthält.

Hier findet sich ein guter Artikel sowie der Downloadlink dazu: https://blogs.technet.microsoft.com/stefan_gossner/2015/09/08/september-2015-cu-for-sharepoint-2013-is-available-for-download/

Viel Erfolg bei der Installation der Updates ;)

Lg,
Chris

Montag, 31. August 2015

SharePoint 2016 IT Preview - Erster Erfahrungsbericht

Werte Leser !

Nachdem letzte Woche die IT Preview von SharePoint 2016 veröffentlicht wurde (download hier), habe ich mich am Wochende einmal mit der Installation und Konfiguration der neuen Version beschäftigt.
Meine Erfahrungswerte möchte ich hier mit euch teilen.

Zunächst einmal ein paar Informationen zur Umgebung, die ich hierzu verwendet habe.

- Virtuelle Maschine unter VMWare Workstation
- Basis - Betriebssystem Windows Server 2012 R2
- SQL Server 2014 SP 1 (alle Versionen davor werden von SharePoint 2016 nicht mehr unterstützt)
- Domain Controller Rolle mit der Domäne mydom.local
- WebServer und Application Server Rolle auf Windows Server
- 150 GB Harddisk
- 10 GB Arbeitsspeicher (mehr ist empfohlen, ich wollte allerdings einen Blick auf die Performance
   werfen und wissen, wie sich die Umgebung mit so knapp bemessenem Arbeitsspeicher verhält)

Nachdem das Basis-Betriebssystem, die Serverrollen, die Domäne und der SQL Server fertig installiert und konfiguriert waren, habe ich in altbewährter Manier mit der Installation der Prerequisites begonnen.




Nach einem zwischendurch erfolgten Reboot, war die Installation der Prerequisites somit auch schnell abgeschlossen. Was hier auffällt ist die Installation eines Microsoft Information Protection and Control Client in Version 2.1 -> Das könnte ein Indiz für die Data Loss Prevention Technik sein, die in SharePoint 2016 Einzug halten wird.

Jetzt wird genau wie in SharePoint 2013 das Setup ausgeführt und danach der Configuration Wizard ausgeführt.



Dieser sieht auf den 1. Blick auch noch aus wie bei SharePoint 2013, bis man zu nachfolgendem Fenster kommt.


Hier besteht nun die Möglichkeit, eine Serverrolle auszuwählen.
Grundsätzlich unterscheidet Microsoft bei SharePoint nun zwischen folgenden Serverrollen:

- Front-end: Alle Services, Service Applications und Komponenten, die die Benutzeranfragen 
  verarbeiten werden bei dieser Serverrolle installiert. Diese Serverrolle ist für high Performance  
  ausgelegt.
- Application: Alle Services, Service Applications und Komponenten für Backend-Requests werden
  bei dieser Serverrolle installiert. Hier ist hoher Durchsatz das Ziel.
- Distributed Cache: Ein Server kann als dedizierter Distributed Cache Server eingesetzt werden.
   Diese Server können optional auch dazu verwendet werden, mittels SharePoint Request Manager
   das Load Balancing einer SharePoint Farm zu übernehmen.
- Search: Alle Services bezüglich der Suche werden bei dieser Serverrolle installiert.
- Custom: Hier kann vom Farm Administrator definiert werden, welche Services auf welchem Server
   installiert und konfiguriert werden sollen.
- Single Server: Diese Konfiguration ist für die Umgebung verwendet worden. In dieser
   Konfiguration werden alle Services und Komponenten auf einem Server bereitgestellt. ACHTUNG:
   Bei dieser Konfiguration ist es NICHT möglich, weitere Server zur Farm hinzuzufügen.

Die restlichen Konfigurationsschritte wie z.B. Angabe des Ports für die Zentraladministration
erfolgen genau so wie in SharePoint 2013. Danach erhält man dann das Abschlussfenster.


Danach öffnet sich wie gewohnt der Internet Explorer, wo man dann die Services von einem Wizard konfigurieren lassen kann. Ich wähle hier immer die Option, die Services selbst zu konfigurieren.

Auf den 1. Blick wirkt die Oberfläche auch sehr stark wie SharePoint 2013 und die Erstellung der Managed Accounts, der Service Applications und ähnliches gestaltet sich auch sehr ähnlich zur Vorgängerversion.

Was bei den Services am Server auffällt ist, dass diese zum einen mit einer neuen Spalte "In Compliance" ausgestattet wurden und zum Anderen nach der Erstellung der Service Application bereits gestartet sind. Dies ist sehr angenehm, da man hier nach der Erstellung der Service Applications nicht noch auf die Services gehen und diese per Hand starten muss.



Ein weiters Detail, das ins Auge springt: Bei dem User Profile Service gibt es KEIN User Profile Synchronization Service mehr. Man findet bei der Konfiguration der Synchronisierung die Auswahlmöglichkeit "User Profile Synchronization" nicht mehr. Man kann lediglich zwischen "AD Import" und "Third Party Identity Manager" wählen - das heißt für mich, dass FIM gestorben ist, was vielen User Profile Service geplagten vermutlich ein Lächeln auf die Lippen zaubert. Die Frage die sich hier stellt ist, wie funktioniert dann das zurückschreiben nach Active Directory ? Dieser Punkt ist noch zu beantworten.

Eine weitere Neuerung ist, dass man die beim Config Wizard angegebene Rolle über die Zentraladministration ändern kann. Wie gut das funktioniert werde ich in Zukunft noch austesten.



Ich habe für einen 1. Testlauf 3 Web Applications und deren Root Site collections angelegt:

- Eine Portalseite (TeamSite Template)
- Ein Enterprise Search Center
- Einen MySite Host

Was auf Anhieb ins Auge sticht ist der schwarze Balken, wo früher ein blauer war. Die Oberfläche sieht sehr stark nach SharePoint Online / Office365 aus, was wiederum für eine engere Integration mit den Cloud Features spricht, damit das Benutzererlebnis möglichst einheitlich ist.

Generell ist der neue alte Look and Feel sehr ähnlich zu SharePoint 2013, aber eben mit einem Hauch mehr Cloud-Feeling. Ein gutes Beispiel dafür ist das Navigationsmenü im linken oberen Bereich, das Office365 Benutzern bereits bestens bekannt sein sollte.




Auch die Dokumentenbibliotheken sollten vom Look and Feel sehr ähnlich der Online-Variante sein.

Das Search Center und der MySite Host sind den Online Varianten auch sehr ähnlich und bringen vom Look and Feel derzeit wenig neues.

Ich werde in den nächsten Wochen und Monaten weiterhin die Details der Neuerungen in SharePoint 2016 in regelmäßigen Abständen hier einstellen und bin für jede Form von Feedback dankbar.

Bis zum nächsten Mal.

Lg,
Chris