Homepage - Consulting-Team-Blog

05.04.2012

Daten-Deduplizierung in Windows Server 8 (Beta)

Daten-Deduplizierung ist an sich nichts Neues. Viele Third-Party-Hersteller von Storage- und Backup-Lösungen bieten diese Funktion seit Jahren an, allerdings ist der Einsatz solcher Systeme häufig mit sehr hohen Kosten verbunden.

Windows Server 8 liefert erstmals eine native, in das Betriebssystem integrierte Deduplizierungslösung. Die grundlegende Funktionsweise beruht dabei auf der effizienten Verwaltung von Daten auf Blockebene mit einer variablen Blockgröße von 32 bis 128 KByte. Redundante Datenblöcke werden in einen von Windows verwalteten Blockspeicher im System-Volume-Information-Abschnitt der Festplatte kopiert. Dies geschieht gewöhnlich im Leerlaufprozess des Servers, so dass die Leistungsfähigkeit des Systems kaum beeinträchtigt wird.

Durch Anwendung dieser Technologie verspricht sich Microsoft eine Deduplikationsrate von 30 – 90% und somit einen enormen Zugewinn an Speicherressourcen. Das gilt es im Folgenden zu überprüfen.

Um dies zu tun, installiert man zunächst den zur Rolle „File Services“ zugehörigen Rollendienst „Data-Deduplication“ hier auf einem Windows Server 8 Datacenter per GUI oder Power Shell.

Anschließend aktiviert man die Deduplizierungs-Funktion für jedes geeignete Volume separat mittels Server Manager im Bereich „File and Storage Services“. Das für den Test vorgesehene Volume hat eine Gesamtgröße von 832 GB. 51,8 GB der Gesamtkapazität sind mit Image-Files bzw. VHDs belegt. Die Daten sind nicht komprimiert.

In diesem Zusammenhang muss beachtet werden, dass die Deduplizierungsfunktion momentan nur von NTFS und nicht vom ebenfalls neu eingeführten Resilient File System (ReFS) unterstützt wird. Zudem kann diese Funktion nicht bei System- bzw. Boot-Volumes angewendet werden.

Neben der eigentlichen Aktivierung der Deduplizierung für das entsprechende Volume, kann man weitere Optionen festlegen (Mindestalter der zu deduplizierenden Dateien, von der Optimierung auszuschließende Dateierweiterungen und Ordner). Anschließend hat man die Möglichkeit über „Set Deduplication Schedule“ die Deduplizierung des ausgewählten Volumes zu planen.

Dabei kann man festlegen, die Deduplizierung im Hintergrund (mit niedriger Priorität, zu Niedriglastzeiten) oder zu festgelegten Zeiten (mit normaler Priorisierung und Ressourcenkonsum) durchlaufen zu lassen. Es besteht ebenfalls die Möglichkeit, die Planung übergreifend für alle Volumes eines Servers festzulegen.

Dazu navigiert man in die Serverübersicht und wählt dort „Deduplication Schedule“ aus. Die oben beschriebenen Einstellungen für die einzelnen Volumes kann man auch global für den kompletten Server setzen, so dass nicht jedes Volume separat konfiguriert werden muss.

Wie bei allen Rollendiensten kann man auch hier PowerShell zur Administration und Einrichtung der Deduplizierungsfunktion nutzen und somit das Handling vereinfachen.

Hier die wichtigsten Befehle im Überblick:

Aufzählung aller verfügbaren Dedup cmdlets:

help Dedup

Aktivierung der Deduplizierung für ein Volume:

Enable-DedupVolume <vol: Or Mount path>

Festlegen des Mindestalters der Dateien (hier: 0 = sofortige Optimierung):

Set-DedupVolume <vol: Or Mount path> -MinimumFileAgeDays 0

Sofortiges Starten der Deduplizierung:

Start-DedupJob <vol: Or Mount path> –Type Optimization

Statusansicht aktueller Optimierungs-Jobs:

Get-DedupStatus

Rückführen der bereits optimierten Daten in den Ursprungszustand:

Start-DedupJob -Volume <vol: Or Mount path> -Type Unoptimization

Soweit so gut, aber wie sieht nun das Resultat der Deduplizierung für das gewählte Volume aus?

Das Ergebnis ist bemerkenswert. Bei einer erreichten Deduplikationsrate von 84% ergibt sich eine effektive Einsparung von 27,7 GB auf dem Volume. Durch die Art der verwendeten Daten war zwar ein guter Komprimierungsgrad absehbar, das erzielte Ergebnis übertraf die Erwartungen jedoch deutlich. Zusammenfassend kann man feststellen, dass die Konfiguration der Windows Server Deduplizierung sehr einfach gehalten ist und zu massiven Speicherplatzeinsparungen bei NTFS-Volumes führen kann.

Bereitgestellt um 08:00 von Kay Seiffert | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

19.03.2012

Kontakte nicht auswählbar mit Lync

In vielen Exchange Organisationen werden besonders oft benötigte externe Ansprechpartner als Kontakte angelegt. Das kann so weit gehen, dass Firmen die viel zusammen arbeiten Ihr ganzes Adressbuch miteinander synchronisieren. Damit sind diese Ansprechpartner direkt aus dem Adressbuch auswählbar. Wenn jetzt beide Firmen eine Lync Server 2010 Infrastruktur betreiben, werden sie sich vielleicht wundern, dass sie diese Kontakte mit dem Lync Client zwar anrufen können, ein Verbindungsaufbau per Lync Client z. B. per Chat ist aber nicht möglich. Die entsprechenden Felder sind nicht aktiviert, also “ausgegraut”:

Dagegen sollte ein Benutzer, den sie mit Lync erreichen können so aussehen:

Lösung:

Diese Kontakte haben keine SIP-Adresse hinterlegt. Es reicht nicht eine Emailadresse zu definieren. Die SIP-Adresse wird im Active Directory (AD) über das Attribut “msRTCSIP-PrimaryUserAddress” festgelegt. Die SIP-Adresse ist in vielen Fällen gleich der Emailadresse, muss es aber nicht. Vergeben Sie dieses Attribut also für die entsprechenden Benutzer entweder:

über die AD-MMC auf der Registerkarte “Attribute Editor” (Hinweis: Advanced Features muss unter Ansicht aktiviert sein) in der Form “sip:SIP-Adresse”

oder mit der Powerhell. Die Power Shell macht sich natürlich leichter, falls sie viele Kontakte ändern müssen. Tipp: Sollte die Emailadresse und die SIP-Adresse identisch sein, lesen sie die Emailadresse aus und übergeben diesen Wert mit Hilfe eines Scripts.
Nutzen Sie einen sog. Verzeichnisabgleich für die Erstellung der Kontakte (z. B. Galsync) nehmen sie das Attribut “msRTCSIP-PrimaryUserAddress” in die Synchronisation mit auf.

Bereitgestellt um 10:42 von Michael Sahr | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

16.03.2012

Möglichkeiten des Verbundes von Exchange Organisationen (Exchange 2010)

Dieser Artikel soll die Möglichkeiten des Verbundes von Exchange Organisationen beschreiben. Mit dem Verbund von Exchange Organisationen werden meistens zwei Aufgaben zusammengefasst:

Aufrufen des externen Kontaktes direkt aus dem Globalen Adressbuch und
Einsehen der Frei- und Gebucht Zeiten

Aufrufen des externen Kontaktes aus dem Globalen Adressbuch

Voraussetzung dafür ist, dass sich dieser Kontakt in Ihrem Globalen Adressbuch befindet. Nur damit ist es möglich Benutzer anderer Exchange Organisationen aus dem Globalen Adressbuch (GAL) aufzurufen. Dafür bieten sich Mailkontakte oder Mail Benutzer an. Der Unterschied ist, dass Kontakte sich nicht lokal an Ihrem Active Directory (AD) anmelden können, Mail Benutzer aber schon.

TIPP: Haben Sie später mal vor die Exchange Organisationen zusammenzuführen, nehmen Sie gleich Mail Benutzer. Ein Kontakt lässt sich nicht in einem Mailbox Benutzer umwandeln und müsste gelöscht werden und dann als neuer Benutzer angelegt werden. Stattdessen lässt sich ein Mail Benutzer leicht in einen Mailbox Benutzer umwandeln.

Wie kommen diese Objekte jetzt ins AD? Mehrere Wege sind möglich: Unterscheidungen bei den aufgeführten Lösungen gibt es in der Funktion und natürlich beim Aufwand und den Kosten. So kommen mehrere Ansätze in Betracht, die ich hier kurz beschreiben möchte und dabei auf Vor- und Nachteile hinweise (diese Aufstellung erhebt nicht den Anspruch auf Vollständigkeit):

Sind es nur wenige Objekte legen Sie diese per Hand an. Wichtig: Das AD Attribut “targetAddress” muss mit der externen Emailadresse gefüllt werden, also z. B. smtp:Kontakt@firma.de.

Vorteil: keine Kosten für Software, kein Trust zwischen den Exchange Organisationen erforderlich

Nachteil: macht nur Sinn bei einigen wenigen Objekten, ansonsten hoher Arbeitsaufwand

Power Shell. Haben Sie Programmiererfahrung? Dann haben Sie vielleicht schon alle Werkzeuge in der Hand die Sie benötigen. Seit Windows 2008 R2 und mit der Powershell ist es möglich eigene Scripte zu entwickeln oder verfügbare Scripte zu verwenden. Ein richtiger Verzeichnisabgleich ist aber keine triviale Angelegenheit. Zu berücksichtigen sind Änderungen an Objekten, Löschungen, Konfliktbehandlung, etc.

Vorteil: keine Kosten für Software

Nachteil: Programmierkenntnisse erforderlich, kein Support, hoher Einarbeitungsaufwand, Trust zwischen den Exchange Organisationen ist hilfreich und vereinfacht die Umsetzung

Active Directory Migration Toolkit (ADMT). Das ist das Universalwerkzeug von Microsoft, eigentlich gedacht zur Umstrukturierung von Domänen.

Vorteil: keine Kosten für Software

Nachteil: Hoher Einarbeitungsaufwand, zusätzliche Hardware erforderlich, SQL Datenbank erforderlich, Trust zwischen den Exchange Organisationen erforderlich.

Quest ActiveRoles Quick Connect Express, ein kostenloses Tool der Firma Quest. Eine Step-by-Step Anleitung finden Sie hier: http://www.open-a-socket.com/index.php/2010/12/23/gal-sync-with-quest-quick-connect-express-for-active-directory/

Vorteil: keine Kosten für Software, relativ einfache Konfiguration, kein Trust zwischen den Exchange Organisationen erforderlich

Nachteil: zusätzliche Maschine erforderlich, SQL Datenbank erforderlich

Galsync, ein kostenpflichtiges Tool der Firma Netsec (www.netsec.de). Die Art des Austauschs der zu synchronisierenden Daten kann dabei ausgewählt werden. Möglich ist der Abgleich per Mail, FTP, Fileshare oder manuell über den Import einer Datei. Die Einrichtung ist schnell erledigt.

Vorteil: sehr einfache Konfiguration, kein Trust zwischen den Exchange Organisationen erforderlich, keine zusätzliche Hardware erforderlich, Support erhältlich

Nachteil: Kostenpflichtig

Microsoft Forefront Identity Manager (FIM). Für diesen Zweck eher unterfordert, aber eigentlich das von Microsoft vorgesehene Produkt für diese Aufgabe.

Vorteil: Support erhältlich

Nachteil: Kostenpflichtig, zusätzliche Hardware erforderlich, hoher Einarbeitungsaufwand

Schon an dieser Stelle müssen Sie sich also entscheiden, wollen Sie den schnellen Erfolg oder verfügen Sie über genug Zeit zur Einarbeitung und Durchführung. Denken sie daran, dass auch Ihre Arbeitszeit Geld kostet.

Einsehen der Frei- und Gebucht Zeiten

Gerade die Bereitstellung von Frei- und Gebucht Zeiten ist für viele Firmen ein Thema, sei es beispielsweise bei Firmenzusammenschlüssen oder bei Kooperationen. Darunter zu verstehen ist z. B. die Möglichkeit bei Besprechungsanfragen gleich einzusehen, ob der Besprechungspartner zu einem geplanten Termin überhaupt verfügbar ist.

Das Vorhandensein der Kontakte im eigenen AD ist bei den folgenden Lösungen Voraussetzung für das Einsehen der Frei- und Gebucht Informationen. Es ist weiterhin eine Vereinfachung für den Benutzer, denn er kann direkt aus dem Adressbuch den Kontakt (z. B. in Outlook oder Outlook Web App) auswählen.

Auch hier möchte ich Ihnen einige Möglichkeiten vorstellen und Vor- bzw. Nachteile auflisten:

Konfigurieren des Verfügbarkeitsdienstes für Cross-Forest Topologien

In Exchange 2010 kann man den Verfügbarkeitsdienst so konfigurieren, dass eine andere Exchange Organisation über die Exchange Web Services (EWS) Zugriff auf die Frei- und Gebucht Informationen erhält. Nähere Informationen zur Konfiguration erhalten Sie im Technet http://technet.microsoft.com/de-de/library/bb125182.aspx. Dabei wird zwischen vertrauenswürdigen und nicht vertrauenswürdigen Gesamtstrukturen unterschieden.

Nicht vertrauenswürdige Gesamtstrukturen. Hier kann der Verfügbarkeitsdienst nur so konfiguriert werden, dass alle Benutzer der anderen Exchange Organisation Zugriff auf die Frei- und Gebucht Informationen erhalten. Sie können keinen Benutzer der externen Organisation einschränken, so wie Sie es mit Benutzern Ihrer internen Organisation tun können und es werden immer nur die Frei- und gebucht Zeiten ohne Details angezeigt:

Der Verfügbarkeitsdienst kann nur über die Exchange Power Shell konfiguriert werden. Diese Schritte müssen in beiden Exchange Organisationen ausgeführt werden. Erstellen Sie weiterhin dazu einen Service Account. Folgende Befehle sind für die Konfiguration des Verfügbarkeitsdienstes notwendig:

Set-AvailabilityConfig -OrgWideAccount "Contoso.com\Service-Account"

$a = get-credential (Eingabe der Credentials des erstellten Service-Accounts in der Form contoso.com\Service-Account)

Add-AvailabilityAddressspace -Forestname Contoso.com -Accessmethod OrgWideFB -Credential:$a

Vertrauenswürdige Gesamtstrukturen. Hier können Sie den Verfügbarkeitsdienst auf Benutzerbasis konfigurieren. Damit ist es möglich detaillierte Informationen über die Frei- und Gebucht Informationen zu erhalten. Für diese Konstellation ist aber ein sog. Forest Trust notwendig. Es wäre möglich, dass diese erweiterten Rechte nicht gewünscht sind.

Galsync

Dieses bereits erwähnte (kostenpflichtige) Tool bietet auch die Möglichkeit des Abgleich der Frei- und Gebucht Zeiten. Die Besonderheit ist hier, dass dazu Öffentliche Ordner herangezogen werden und nicht die EWS benutzt werden, deshalb kann es auch ohne weitere Voraussetzungen in Exchange Organisationen benutzt werden, die noch ältere Versionen als Exchange 2010 einsetzen. Das bedeutet aber, dass eine Öffentliche Ordner Datenbank vorhanden sein muss. Zu erwähnen bleibt, dass bei dieser Lösung keine detaillierten Informationen der Frei- und Gebucht Zeiten zur Verfügung stehen, da diese Informationen in der Öffentliche Ordner Datenbank nicht vorhanden sind.

Exchange Federation

Eine gewisse Sonderstellung stellt eine Exchange Federation dar. Sie ist unabhängig von dem Abgleich der GAL und benötigt keinen Trust zwischen den Organisationen. Nur wenn Sie die Empfänger direkt aus dem Adressbuch auswählen wollen, benötigen Sie weiterhin die Synchronisierung der GAL. Ansonsten geben Sie einfach die Emailadresse z.B. bei einer Besprechungsanfrage ein. Auch ist es hier möglich den Detailgrad der Frei- und Gebucht Zeiten zu konfigurieren.

Zuerst wird über einen speziellen (kostenfreien) Dienst von Microsoft, dem sog. Microsoft Federation Gateway (MFG) eine Federation aufgebaut. Dabei fungiert das MFG wie ein Vermittler und erhält ein Token. In der anderen Exchange Organisation muss ebenfalls diese Federation zum MFG aufgebaut werden. Mit diesem Token geht Exchange dann zu dem Exchange Server der anderen Organisation. Da die andere Exchange Organisation dem Token vertraut, da es ja dem MFG vertraut, kann der Token zur Authentifizierung genutzt werden. Es müssen einige Vorbedingungen erfüllt sein, damit die Einrichtung gelingt: z. B. muss Autodiscover und EWS korrekt konfiguriert sein und es muss die Domain-Eigentümerschaft der eigenen Emaildomain dem MFG bestätigt worden sein (z. B. über TXT Einträge im öffentlichen DNS). Die gesamte Kommunikation ist mit SSL verschlüsselt. Zur eigentlichen Konfiguration können Sie den “New Federation Trust Wizard” benutzen. Näheres im Technet unter http://technet.microsoft.com/de-DE/library/dd335047.aspx.

Sobald die Federation mit dem MFG aufgebaut ist, sind sie in der Lage mit jeder anderen Organisation die ebenfalls eine Federation mit dem MFG betreibt, Frei- und Gebucht Zeiten einzusehen bzw. Kalenderabfragen durchzuführen.

Exchange Federation können auch in Exchange Organisationen aufgebaut werden, in denen es Exchange Versionen vor Exchange 2010 gibt. Voraussetzung ist allerdings das Vorhandensein eines Exchange 2010 Client Access Servers (CAS) in der Exchange Organisation, der dann die EWS bereitstellt.

Sollte Sie weitere Nachfragen zu diesem Thema haben oder falls Sie Hilfe bei der Implementierung benötigen, können Sie sich gerne an uns wenden!

Bereitgestellt um 10:23 von Michael Sahr | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

SharePoint 2010 Versionsnummern (Update)

Die ersten kummulativen Update Pakete für SharePoint 2010-Produkte sind veröffentlicht worden.

Nun beginnt also auch hier die Zeit, in der es nicht schaden kann, den Überblick über die entsprechenden Versionsnummern zu behalten.

Prüfen kann man die eigenen Versionnummern wie folgt (via Todd Klindt):

Farm
Central Administration > System Settings > Manage servers in this farm
(/_admin/FarmServers.aspx)
Komponenten
Central Administration > Upgrade and Migration > Check Product and patch installation status
(/_admin/PatchStatus.aspx)
Datenbanken
Central Administration > Upgrade and Migration > Review database status
(/_admin/DatabaseStatus.aspx)

Version	Updatepaket	Links
14.0.6117.5002	Cummulative Update (CU) February 2012	KB2597132, KB2597150, KB2597152
14.0.6114.5000	Cummulative Update (CU) December 2011	KB2597058, KB2597014, KB2597015
14.0.6112.5000	Cummulative Update (CU) October 2011	KB2596508, KB2596505, KB2596506
14.0.6109.5002	Cummulative Update (CU) August 2011	KB2553048, KB2553049, KB2553050
14.0.6106.5002	Cummulative Update (CU) June 2011	KB2536601, KB2536599, KB2536600
14.0.6029.1000	Service Pack (SP) 1	Liste aller Pakete
14.0.5138.5001	Cummulative Update (CU) April 2011	KB2512804, KB2512800, KB2512801
14.0.5136.5002	Cummulative Update (CU) February 2011	KB2475880, KB2475878, KB2475879
14.0.5130.5002	Cummulative Update (CU) December 2010	KB2459125, KB2459257, KB2459258
14.0.5128.5000	Cummulative Update (CU) October 2010	KB2394323, KB2394320, KB2394322
14.0.5123.5000	Cummulative Update (CU) August 2010	KB2352346, KB2352342, KB2352345
14.0.5114.5003	Hotfix Packages June 2010	KB2028568, KB983497, KB2281364, KB2204024, KB2075990
14.0.4762.1000 14.0.4763.1000	Release to manufacturing (RTM)	SharePoint Foundation 2010 SharePoint Server 2010 Trial

Short-URL zu diesem Beitrag: http://bit.ly/sp2010builds

Bereitgestellt um 09:00 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

21.12.2011

VMware ESXi speichert die Konfiguration nicht

Bei meiner letzten ESXi 5.0 Installation hatte ich folgendes Problem:

Nach jedem Reboot verlor der Host seine Netzwerkeinstellungen. Damit ist der Host schlimmstenfalls über Netzwerk gar nicht mehr erreichbar. Vielleicht hätte eine feste DHCP Reservierung geholfen, aber oft kommt eine Reservierung gar nicht in Frage.

Lösung:

Alle Einstellungen werden in der sog. Bootbank-Partition gespeichert. Einmal in der Stunde läuft ein Cron-Job der die aktuelle Konfiguration abspeichert. Anscheinend lief dieser Job noch nicht oder versagte. Warum diesen Job also nicht per Hand starten? Dafür an der Konsole oder per SSH folgenden Befehl ausführen:

/sbin/auto-backup.sh

Danach startete der ESXi mit den gespeicherten Konfigurationseinstellungen.

Bereitgestellt um 12:27 von Michael Sahr | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

09.12.2011

Einrichtung eines Kerberos Account für Lync

Microsoft Lync Server 2010 ist von Hause aus ziemlich sicher, da sämtliche Verbindungen zwischen Client und Server verschlüsselt werden. Auch die Kommunikation zwischen einzelnen Lync-Diensten erfolgt per https oder TLS-gesichert. Aus diesem Grund sind für sämtliche Lync Server entsprechende Zertifikate erforderlich. Deshalb gibt es weinige Einstellungen, die die Konfiguration einer Lync 2010 Umgebung sicherer machen würden.

Eine zusätzliche Einstellung die vorgenommen werden kann, wird im den Microsoft Lync Server 2010 Security Guide unter dem Punkt Protecting IIS beschrieben. Nachfolgend liste ich die erforderlichen Power Shell Befehle für die Einrichtung eines solchen Accounts auf:

Schritt 1 – Anlegen eines Kerberos-Authentifizierungskonto

New-CsKerberosAccount -UserAccount "Domain\Lync_Kerb_Id" -ContainerDN "OU=Users,DC=domain,DC=com"

Anmerkungen:

· Der Name des Kerberosaccounts kann natürlich frei gewählt werden, darf aber nicht länger als 14 Zeichen sein.

· Es wird ein Computerobjekt in der angegebenen OU erstellt. Es kann natürlich auch eine andere OU gewählt werden.

Schritt 2 – Ermitteln der Site

Get-cssite | fl identity

Schritt 3 - Zuweisen eines Kerberos-Authentifizierungskontos zu einem Standort

New-CsKerberosAccountAssignment -UserAccount "Domain\Lync_Kerb_Id" -Identity "Site:Sitename"

Schritt 4 – Veröffentlichen der Topologie

Enable-CsTopology

Schritt 5 – Festlegen von Kennwörtern für das Kerberos-Authentifizierungskonto

set-CsKerberosAccountPassword -UserAccount "Domain\Lync_Kerb_Id"

Schritt 6 – Veröffentlichen der Topologie

Enable-CsTopology

Zur Überprüfung kann man folgenden Befehl absetzen:

Test-CsKerberosAccountAssignment -Identity "site:Sitename" -Report "c:\report.htm" –Verbose

Links: http://technet.microsoft.com/de-de/library/gg398976.aspx

Bereitgestellt um 13:02 von Michael Sahr | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

07.12.2011

Reporting über Daten in verknüpften SharePoint Listen

SharePoint Listen stellen eine einfache Möglichkeit dar, gemeinsam an tabellenartig darstellbaren Daten wie z.B. Projekten, Kunden oder dem Inventar, zu arbeiten. Über Microsoft Excel und Access lassen sich die Daten auch ganz vorzüglich auf dem Client auswerten.

Das Reporting über SharePoint Listendaten gestaltet sich jedoch unweit schwieriger, sobald Informationen aus anderen SharePoint Listen referenziert werden (Lookup-Werte/Nachschlagespalten).

Auswertung mit Excel

Bei der Auswertung von SharePoint Listen mit Hilfe von Microsoft Excel sind Pivot-Tabellen grundsätzlich ein hervorragendes Hilfsmittel. Als Datenquelle kann eine SharePoint-Liste dienen, mit deren Hilfe Daten und Auswertung on demand aktualisiert werden können.
Diese Methode ist bei Nachschlage-Feldern jedoch in zweierlei Hinsicht problematisch: Zum einen werden die Werte aus der “fremden” Liste im Format <Anzeigewert>;#<IDderNachschlageliste> angezeigt. Zum Anderen kann sich eine Pivot-Tabelle immer nur auch eine Datenquelle beziehen. Eine Auswertung über verknüpfte Daten gestaltet sich damit schwierig (z.B. mit Hilfe einer Mapping-Tabelle).

Auswertung mit Access

Auch Access kann die Daten aus einer SharePoint Liste beziehen und kann somit Auswertungen bereitstellen, die sich stets auf den aktuellsten Datenbestand beziehen.

Dabei bleiben die Daten und ihre Beziehungen erhalten, was den großen Vorteil birgt, das entsprechende Abfragen in SQL formuliert und ausgeführt werden können. Doch auch gibt es einen limitierenden Faktor: Wird die Ergebnismenge zu groß erreicht man schnell das Limit für die Anzahl an Nachschlagewerten und man erhält in der Folge überhaupt kein Ergebnis. Für einen größeren Datenbestand erscheint dieses Verfahren folglich ebenfalls ungeeignet.

Überführung der Daten in ein “Data Warehouse”

Für größere Datenbestände scheint es also überlegenswert, die Daten aus den SharePoint Listen in “echte” SQL Datenbanken zu überführen. Für diesen Ansatz lieferen die frei verfügbaren Microsoft SQL Server Community Samples: Integration Services das notwendige Werkzeug: SharePoint List Source and Destination. Diese Adapter ermöglichen es, SharePoint Listen in sog. SQL Server Integration Services (SSIS) “Data Flows” als Quelle und Ziel zu verwenden.

Damit ist es beispielsweise möglich, die Datenbeziehungen in Form von Tabellen, Primärschlüsseln und Relationen in einer SQL Server Datenbank zu definieren und regelmäßig mit Daten aus SharePoint zu befüllen (“Data Warehouse”). Die Ergebnismenge lässt sich dann mit Hilfe von Ansichten, gespeicherten Prozeduren, SQL Server Reports, SQL Server Analysis Services Datenquadern etc. etc. auswerten und visuell aufbereiten.

Bei dieser Variante hat stellt sich jedoch, analog zur Excel Methode, die Herausforderung, dass die einzelnen SharePoint Listen, Lookup-Werte als <Anzeigewert>;#<IDderNachschlageliste> zurückgeben. Zur Auflösung in “echte” IDs, die dann zur Defintion von Relationen verwendet werden können, kann dem SSIS Data Flow beispielsweise eine sog. “Derived Column Transformation” hinzugefügt werden, die zwischen SharePoint-Quelle und SQL Server-Ziel platziert wird und Transformationen vornimmet.

Beispielhaft sei die folgende Transformation genannt, die aus einem einzelnen Nachschlage-Wert die ID extrahiert:

(LEN(Kunde) == 0 ? NULL(DT_I4) : (DT_I4)(SUBSTRING([Kunde],1,(FINDSTRING([Kunde],";",1)) - 1)))

Diese Tranformation prüft, ob das Feld “Kunde” überhaupt einen Wert enthält. Für Nachschlage-Spalten handelt es sich bei den Werten um ein einfache Zeichenketten. Ist die Länge der Zeichenkette 0, soll eine SQL-NULL Information gespeichert werden. Anderfalls wird die Zeichenkette nach dem Trennzeichen “;” durchsucht und die entsprechende Teilzeichenkette, die die ID enthält, extrahiert und in Integer konvertiert. In der SQL Server Datenbank landet also nur die “echte” ID des Kunden.

Die SharePoint List Destination-Komponente scheint damit hervorragend geeignet, über einen Umweg detailierte Auswertungen über Informationen in verknüpften SharePoint Listen zu erstellen.

Bereitgestellt um 16:24 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

28.09.2011

SharePoint 2010 Inhaltsdatenbanken in PowerShell / Datenbankupgrades nach Patches

Verfügbare Cmdlets in PowerShell

Um die Inhaltsdatenbanken einer SharePoint-Farm mit Windows PowerShell abzufragen, stehen zwei unterschiedliche Cmdlets zur Verfügung:

Get-SPContentDatabase und
Get-SPDatabase

Nun könnte man davon ausgehen, dass der einzige Unterschied zwischen den beiden Varianten ist, dass die erstgenannte die Abfrage selbstständig auf Inhaltsdatenbanken beschränkt, während die andere alle Datenbanken zurückgibt. Nun, die Annahme, Get-SPDatabase lieferte alle Datenbanken stimmt immerhin. Leider liefert Get-SPContentDatabase nicht immer alle Inhaltsdatenbanken, wie im Folgenden ersichtlich werden soll. Darüber hinaus gibt es eine Reihe weiterer Parameter die sich unterscheiden, auf die in diesem Artikel aber nicht weiter eingegangen werden soll.

Die Unterschiede

Zuerst einmal betrachten wir die Ausgabe von Get-SPContentDatabase ohne Parameter (im abgebildeten Screenshot wird noch Transformation in eine Tabellendarstellung ausgeführt, um eine angenehmere Darstellung zu erhalten):

Clipboard01

Von Get-SPDatabase ist bereits bekannt, dass alle Datenbanken zurückgegeben werden, deswegen sollen diese direkt auf Inhaltsdatenbanken beschränkt werden:

Get-SPDatabase | ? {$_.Type –like '*Content*' }

Es fällt auf, dass hier auch die Inhaltsdatenbank der Zentraladministration angezeigt wird.

Der gravierende Unterschied wird aber deutlich, wenn man eine Datenbank anlegt, die, nachdem z.B. eine einzige SiteCollection dort platziert wurde, für weitere Site Collections nicht verwendet werden soll:

Nun führt man wieder die beiden verschiedenen Cmdlets aus:

Get-SPContentDatabase

Get-SPDatabase | ? {$_.Type –like '*Content*' }

Hier also der gravierende Unterschied: Während Get-SPDatabase Inhaltsdatenbanken, die keine weiteren SiteCollections aufnehmen können anzeigt, werden diese bei Get-SPContentDatabase nicht angezeigt!

Anwendungsbeispiel

Kommen wir nun zu einem praktischen Anwendungsbeispiel: Alle zwei Monate veröffentlicht Microsoft kummulative Update-Pakete für die SharePoint Produkte. Oftmals beheben diese weit verbreitete Probleme, sodass ein Großteil unserer Kunden diese Pakete ebenso regelmäßig installiert.

Jede Update-Installation macht die Ausführung des SharePoint Configuration Wizards erforderlich, durch dessen Routinen unter anderem die Änderungen an den Strukturen (Schema) der Datenbanken vorgenommen werden.

Leider ist vermehrt zu beobachten, dass der Configuration Wizard regelmäßig während der Upgrades der Inhaltsdatenbanken mit einer Fehlermeldung abbricht. Deshalb ist es empfehlenswert die Inhaltsdatenbanken vor dem Ausführen der Upgrades durch den Configuration Wizard abzuhängen. Bei sehr vielen Datenbanken kann man da schon einmal den Überblick verlieren, welche Inhaltsdatebank zu welcher Web-Applikation gehört und ob diese Datenbank gestoppt war oder nicht.

Deshalb möchte ich einen Weg aufzeigen, wie man diese Informationen von PowerShell erzeugen, sichern und wieder einlesen kann.

Nun haben wir ja gelernt, dass wir Get-SPDatabase verwenden sollten, um auch gestoppte Datenbanken zu erfassen. Diese Ausgabe passen wir so an, dass zusätzlich sowohl die entsprechende Web-Applikation-URL als auch der Status der Datenbank ausgegeben werden. Hierfür kann unter anderem Select-Object verwendet werden. Anschließend werden die Ergebnisse noch ohne Typeninformation in das CSV-Format konvertiert und ins Dateisystem geschrieben. Anschließend werden alle diese Datenbanken von den Web-Applikationen abgehängt.

$dbs = Get-SPDatabase | ? { $_.Type -like '*Content*' }
$dbs | Select-Object -Property Name,@{Name='WebApplication';Expression = {$_.Webapplication.Url}},Status | ConvertTo-Csv -NoTypeInformation | Out-File MyDBs.csv
$dbs | Dismount-SPContentDatabase

Im Anschluß an die Fertigstellung dieses Kommandos kann dann der Configuration Wizard ausgeführt werden.

Ist dieser erfolgreich durchgelaufen, wird die vorher erzeugte *.csv-Datei wieder eingelesen und jede einzelne Datenbank wieder an die usprüngliche Web-Applikation angehängt.

$mydbs = Import-Csv .\MyDBs.csv
$mydbs | ForEach-Object { Mount-SPContentDatabase -Name $_.Name -WebApplication $_.WebApplication }

Leider wird dabei nicht der ursprüngliche Status wiederhergestellt. Diesen muss man entweder manuell über die Zentraladministration erneut setzen oder z.B. das oben genannte Skript um die folgende Logik innerhalb des ForEach-Object Anweisungsblocks erweitern (hier exemplarisch für die Datenbank mit dem Index 2):

$mydbs[2].Status = "Disabled"
$mydbs[2].Update()

Bereitgestellt um 13:21 von Helge de Vries | Kategorie: SharePoint | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

19.08.2011

Office 365 Einrichtung - Teil 4

Nachdem im dritten Teil das Single Sign-On für die Domäne msfairs.com eingerichtet wurde, folgt in diesem Teil die Synchronisierung (Directory Synchronization oder DirSync) der Benutzer aus dem lokalen (On-Premise) Active Directory in die Office 365 Cloud.

Während das Single Sign-On nur die für die Benutzeranmeldung zuständig ist, synchronisiert DirSync Attribute der lokalen Active Directory Benutzer wie zum Beispiel den Namen, die E-Mail Adresse oder Telefonnummern. Unter Synchronisation wird in diesem Zusammenhang das Kopieren von Attributen vom lokalen Active Directory in die Office 365 Cloud verstanden. Von Office 365 werden keine Attribute zurückkopiert.

Die Installation und Konfiguration wird ausschließlich auf Server SRV03 durchgeführt; von diesem Server werden auch die Office 365 Dienste per PowerShell für die Directory Synchronization konfiguriert.

Als Betriebssystem für DirSync muss ein 32-bit (x86) Windows Server 2003 oder Windows Server 2008 zum Einsatz kommen. Windows Server 2008 R2 wird nicht unterstützt! Des Weiteren darf DirSync nicht auf einem Domänencontroller installiert werden. Hier kann man die genauen Anforderungen nachlesen.

Aktivierung der Directory Synchronization

Vor der Installation von DirSync muss die Active Directory Synchronization im Office 365 Portal aktiviert werden (Screenshot, Schritt 3). Zurzeit ist es nicht möglich, diese Aktivierung rückgängig zu machen! Des Weiteren sollte das Single Sign-On bereits eingerichtet sein und funktionieren.

Installation von DirSync

Das DirSync Tool, welches zur Zeit eine spezielle Version des Microsoft Identity Lifecycle Manager 2007 (ILM) ist, wird ebenfalls über das Office 365 Portal heruntergeladen.

Vor der Installation muss das Windows Feature Windows PowerShell installiert werden.

Außerdem muss das .NET Framework 3.5 oder höher installiert sein. Das

.NET Framework 3.5 Service Pack 1 (Full Package) kann hier heruntergeladen werden.

Die eigentliche Installation ist eine klassische Weiter … Weiter … Fertig … Installation bei der lediglich der Installationsordner angegeben werden kann.

Der letzte Schritt Installing Components kann schon mal ein paar Minuten (bei mir etwa 15 Minuten) dauern.

Wie bei der Installation von AD FS findet nach der Installation des Tools die Konfiguration statt.

On-Premise Active Directory und Office 365 verbinden

Für die Herstellung der Verbindung wird einmalig der Configuration Wizard ausgeführt. Dafür ist die Eingabe eines On-Premise Active Directory Enterprise Administrators und eines Global Administrators in Office 365 notwendig. Das Benutzerkonto und Kennwort des On-Premise Benutzers wird nur einmalig benötigt und danach nicht mehr verwendet; Benutzername und Kennwort des Global Administrators in Office 365 werden hingegen gespeichert und bei jeder Synchronisierung verwendet.

Nach Abschluss der Synchronisation sind alle Benutzer und Gruppen des On-Premise Active Directory als User in Office 365 vorhanden.

Wie bereits beschrieben, können die Attribute der Benutzer oder Gruppenmitgliedschaften nur im Active Directory geändert werden. Alle drei Stunden findet eine automatische Synchronisation statt; bei Bedarf kann eine Synchronisation manuell durchgeführt werden.

Nach der erfolgreichen Synchronisation müssen den Benutzern noch Office 365 Lizenzen zugewiesen werden. Das kann man im Office 365 Portal oder per PowerShell machen.

Arbeiten mit Office 365 aus Benutzersicht

Nachdem das Single Sing-On und DirSync eingerichtet wurde können sich die Benutzer am Office 365 Portal anmelden. Gibt Benutzer einen Benutzernamen an, der zu einer Domäne gehört, die für das Single Sign-On eingerichtet wurde, wird er zum lokalen AD FS Server geleitet und muss sich hier authentifizieren.

Je nach Konfiguration des Browsers (Lokale Intranetzone) wird der Benutzer automatisch am AD FS Server angemeldet (für den Screenshot habe habe ich den AD FS Server aus der Lokalen Intranetzone entfernt).

und landet wieder im Office 365 Portal, diesmal als authentifizierter Benutzer.

Nachdem DirSync und Single Sign-On eingerichtet wurde, können die Benutzer die Office 365 Dienste so verwenden, als würden sie im lokalen Netzwerk betrieben.

Office 365 Einrichtung - Teil 1: Übersicht

Office 365 Einrichtung - Teil 2: Domäne in Office 365 hinzufügen

Office 365 Einrichtung - Teil 3: Single Sign-On / AD FS

Office 365 Einrichtung - Teil 4: Directory Synchronization

Bereitgestellt um 10:26 von Denis Holtkamp | Kategorie: Office 365 | Permalink | Diesen Beitrag per E-Mail senden | Kommentare (0)

14.07.2011

Office 365 Einrichtung - Teil 3

Nachdem im zweiten Teil der Domänenname msfairs.com zu Office 365 hinzugefügt wurde, wird die Domäne in diesem Teil für das Single Sign-On konfiguriert. Damit können die Benutzer nachdem sie sich am Active Directory angemeldet haben, ohne erneute Authentifizierung auf die Office 365 Dienste zugreifen.

Die Einrichtung des Single Sign-On besteht aus drei Schritten, der Installation von Active Directory Federation Services (AD FS), der Installation des Microsoft Online Services Module und des Aufbaus der Partnerschaft zwischen dem On-Premise AD FS Server und Office 365.

Die Installation und Konfiguration wird ausschließlich auf SRV02 durchgeführt; von diesem Server werden auch die Office 365 Dienste für das Single Sign-On konfiguriert.

Installation von AD FS

Die Active Directory Federation Services 2.0 sollten auf einem Windows Server 2008 R2 bereitgestellt werden. Sie sind – anders als AD FS 1.0 – nicht Bestandteil des Servers und müssen separat heruntergeladen werden. Die Installation ist eine klassische Weiter … Weiter … Fertig … Installation bei der lediglich zu beachten ist, dass ein Federation Server und kein Federation Server Proxy installiert wird.

…

Für Inbetriebnahme von AD FS wird zwingend ein SSL-Zertifikat für die AD FS Webseite und für die Signatur der Tokens benötigt. Da auf Office 365 wahrscheinlich auch nicht verwaltete Clients zugreifen, wird empfohlen ein SSL-Zertifikat einer kommerziellen Zertifizierungsstelle wie zum Beispiel www.trustico.eu oder kostenlose Zertifikate von www.startssl.com.

AD FS Configuration Wizard

Nach dem Einspielen des Zertifikates kann der AD FS Configuration Wizard gestartet werden.

Es wird ein neuer Federation Service erstellt:

Um das Szenario einfach zu halten, erstellen wir einen Stand-alone Federation Server. Für den produktiven Einsatz sollte aus Verfügbarkeitsgründen eine AD FS Farm eingesetzt werden.

Wenn an dieser Stelle kein Zertifikat erscheint, muss das Zertifikat zu dem Computer hinzugefügt werden.

Fertig. Der AD FS Server ist konfiguriert.

Installation des Microsoft Online Services Module

Das Microsoft Online Services Module muss für die Installation aus dem Office 365 Portal heruntergeladen werden. Voruassetzung für die Installation des Moduls ist die Installtion des Microsoft Online Services Sign-In Assistant (IDCRL7), welches ebenfalls aus dem Portal heruntergeladen werden kann.

Beide Installationen sind ebenfalls klassische Weiter … Weiter … Fertig … Installationen

Microsoft Online Services Sign-In Assistant (IDCRL7)

Microsoft Online Services Module

Herstellen der Partnerschaft zwischen On-Premise AD FS und Office 365

Über das Microsoft Online Services Module for Windows PowerShell wird die Partnerschaft zwischen dem On-Premise AD FS und Office 365 aufgebaut.

Dazu werden folgende Commandlets ausgeführt:

#Abfrage der Office 365 Anmeldeinformationen

$cred=Get-Credential –Credential dh@fabianmoriz.onmicrosoft.com

#Verbindung zu Office 365 mit den Anmeldeinformationen aufbauen

Connect-MsolService –Credential $cred

#Lokalen AD FS Server angeben, der konfiguriert werden soll

Set-MsolAdfscontext -Computer SRV02.msfairs.com

#Vorhandene Domäne in eine Federated Domäne Konvertieren

Convert-MSOLDomainToFederated –DomainName msfairs.com

Durch die Commandlets wird bei dem On-Premise AD FS Server das Microsoft Federation Gateway als Partner eingetragen. Die Office 365 AD FS Server werden entsprechend konfiguriert.

Im Office 365 Portal wird der Status der Domain auf

Domain type: Single sign-on: This domain is configured for single sign-on

geändert. Dies ist die Bestätigung, dass die Änderung auch auf Seite von Office 365 angewendet wurde.

Nach Abschluss dieser Änderungen ist ein Single Sign-On möglich.

Um genau zu sein, können sich die Domänenbenutzer jetzt bei Office 365 authentifizieren. Damit die Benutzer auch Zugriff auf Office 365 Dienste bekommen, müssen die Benutzer in Office 365 manuell eingerichtet beziehungsweise synchronisiert werden.
Wenn jetzt ein Benutzer auf Office 365 zugreift, erhält er unten stehende Fehlermeldung. Die Fehlermeldung beschreibt den Zustand korrekt: Der Benutzer ist zwar Authentifiziert, es existiert jedoch kein entsprechender Office 365 Benutzer.