Archiv für April 2013

SCCM 2012 SP1 CU1 – Warum verweigern die ManagementPoints den Dienst?

Donnerstag, 25. April 2013

bildteaser_managementSeit langem melde ich mich mal wieder mit einem Blog über den ConfigMgr 2012 zurück. Nachdem wir nun ein paar Wochen getestet haben, konnte diese Woche das CU1 für den ConfigMgr 2012 SP1 in unser Produktivsystem eingespielt werden.

Und wie das immer so ist, erstens kommt es anders und zweitens als man denkt! In unserer Testumgebung, die dem Produktivsystem absolut gleicht (dachte ich zumindest), verliefen alle Installationen problemlos. Aber als wir das CU1 im Produktivsystem verteilt haben, waren unsere ManagementPoints plötzlich der Meinung ihren Dienst zu verweigern.

Doch warum ist das so?

Nun die MP Rolle sollte vom ConfigMgr automatisch neu installiert werden. Dies blieb jedoch mit der folgenden Commandline in der MPSetup.log hängen:

Installing E:\Microsoft Configuration Manager\bin\x64\mp.msi CCMINSTALLDIR=”E:\SMS_CCM” CCMSERVERDATAROOT=”E:\Microsoft Configuration Manager” USESMSPORTS=TRUESMSPORTS=80 USESMSSSLPORTS=TRUE SMSSSLPORTS=443 USESMSSSL=TRUE SMSSSLSTATE=0 CCMENABLELOGGING=TRUE CCMLOGLEVEL=1 CCMLOGMAXSIZE=1000000 CCMLOGMAXHISTORY=1

Nach genauerem Betrachten des Logs fiel mir ein kleiner syntaktischer Fehler auf:

USESMSPORTS=TRUESMSPORTS=80

Eindeutig: Hier fehlt ein Leerzeichen!

Wir konnten den Fehler nur in unserm Produktivsystem beobachten, auf allen anderen Systemen lief die Installation problemlos durch.

Die entsprechenden Server haben die folgenden Specs:

System: W2k8 R2 SP1
Patchstand: aktuell
ConfigMgr Partition losgelöst von der System Partition.

Sollten Sie dasselbe Problem haben, hilft der Aufruf der Commandline mit privileged Rights. Danach sollte sich der MP wieder normal verhalten!

Autor: Jens Decker

AD DirSync & Single Sign On – Wie synchronisiere ich nur die User, die in die Cloud sollen?

Mittwoch, 17. April 2013

bildteaser_cloud2Nachdem das „Produkt“ Office 365 nun einige Zeit auf dem Markt ist, hat sicherlich jeder CIO schon etwas davon gehört und sich zumindest einmal die Frage gestellt: Bringt es unserem Unternehmen wirklich einen Mehrwert? Ich nenne es übrigens „DIE Innovation in der IT von heute!“ Ich verstehe aber auch die Bedenken der Großunternehmen, die mit einer Vielzahl, meist über 1000, von verschiedensten User-Accounts konfrontiert sind und auf einmal auf DirSync mit Office 365 umstellen sollen. In dieser Situation schlägt erst mal jeder Active Directory Admin die Hände über den Kopf, wenn sein CIO zu ihm sagt, wir aktivieren jetzt DirSync mit Office 365.

 

Es stand für uns als Microsoft Gold Partner und IT-Systemhaus außer Frage Office 365 zu nutzen, denn die von Microsoft betriebenen Rechenzentren entsprechen den höchsten Ansprüchen an Performance, Sicherheit und Redundanz und sind dabei den privaten Rechenzentren deutscher Unternehmen technisch klar im Vorteil sowie deutlich besser gegen Ausfälle und Attacken oder Umweltkatastrophen geschützt. Mehr zu Vertrauen in Office 365 hier.

 

 

 

Doch mir als der erwähnte Admin, der es umsetzten sollte, schossen spontan folgende Begriffe in den Kopf:

  • Service Accounts
  • Administrations Accounts
  • Admin Gruppen
  • Server Gruppen

und noch viele mehr, die wir nicht bei Office 365 haben wollten.

Das Ziel sollte sein, wirklich nur die User zu synchronisieren, welche die Services in der Cloud nutzen sollen. Da der DirSync keine neue Erfindung sondern lediglich eine Kombination aus verschieden Microsofttools ist, sollte es nicht allzu schwer sein, hier eine Lösung zu finden.

Das war es auch nicht. Die Frage war nur, wo setzen wir hier an?

DirSync besteht im Wesentlichen aus zwei Komponenten, dem Forefront Identity Manager (FIM) und der PowerShell. Die PowerShell erledigt das „Doing“. Sie nimmt die vom FIM bereitgestellten Accounts und synchronisiert diese mit Office 365. Nebenbei werden noch Domaininfos aus Office 365 heruntergeladen und im lokalen AD als Logondomain abgelegt.

Was ist nun wichtig?

Wenn ein lokaler AD Name, wie bspw. company.local verwendet wird, müssen Sie die UPN Suffixe Ihrer zu synchronisierenden User an den öffentlichen Domainname anpassen. Beispielsweise würde aus max.mustermann@pt.local = max.mustermann@protechnology.de

Passender Artikel dazu und Lync Migration – die Kommunikation geht in die Cloud”

Autoren: Sascha Blickensdörfer, Jens Decker

Aufgaben-Erinnerungen (Reminder E-Mails) mit SharePoint 2010 automatisch versenden

Freitag, 12. April 2013

bildteaser_automatischIn nahezu jedem SharePoint liegen Aufgabenlisten. Wie jedoch kann ich meine Mitarbeiter darüber auf dem Laufenden halten, welche Aufgaben ihr Fälligkeitsdatum bereits überschritten haben? Am Ende soll eine saubere und lizenzkostenfreie Lösung stehen.

Pragmatisch lässt sich das Problem lösen, indem man eine dedizierte gefilterte Listenansicht erzeugt. Jedoch löst dies nicht die häufig gestellte Anforderung, dass der Aufgabenträger täglich per E-Mail an seine überfällige Aufgabe erinnert werden soll. Dies ruft spontan die bekannten SharePoint Designer-Workflows auf den Plan. Diese haben in SharePoint 2010 jedoch eine gravierende Schwäche: es werden mit Bordmitteln keine Schleifen unterstützt. Dieses Problem ist in SharePoint 2013 aufgrund der innovativen Workflow-Engine nicht mehr vorhanden, jedoch kommt derzeit noch kaum ein Unternehmen in diesen Genuss. Um diese Schleifenproblematik zu lösen, sind im Netz die abenteuerlichsten Konstruktionen in Form von Workarounds zu finden. Diese sind jedoch allesamt aufwendig zu erstellen, nur teilweise zuverlässig und vor allem aufwendig zu warten. Mit der Tatsache, dass SharePoint Designer 2010 Workflows keine Schleifen unterstützen, muss man sich abfinden. Das heißt aber nicht, dass wir unser Problem nicht trotzdem sauber gelöst bekommen.

Zunächst klammern wir die Schleifenproblematik aus uns widmen uns dem Workflow, der die Erinnerungsnachricht an den Aufgabenträger verschickt. Zu tun haben wir es mit einer gewöhnlichen Aufgabenliste. Interessant für den Prozess sind zunächst der Status der Aufgabe und das Fälligkeitsdatum.

Anschließend öffnen wir die Aufgabenliste mit dem SharePoint Designer und fügen einen Workflow an die Liste an. Wichtig ist, dass der Worklow so konfiguriert sein muss, dass er manuell gestartet werden kann. Aber dazu später mehr. Der Ablauf ist zunächst sehr einfach gehalten. Unter der Voraussetzung von drei einfachen Bedingungen soll eine Erinnerung an den Aufgabenträger versandt werden.

Die Mail selbst kann neben Textinhalten zusätzlich mit Hilfe von Platzhaltern mit Daten aus dem Datensatz angereichert werden. Die Platzhalter-Daten selbst lassen sich unterschiedlich formatieren.

Es empfiehlt sich, die genannte Aufgabe mit einem Hyperlink in der Mail zu versehen. Dies ist nicht ganz trivial und muss einer bestimmten Syntax entsprechen. Wichtig ist vor allem, dass bei der Verwendung von benutzerdefinierten Formularen die korrekte Formularbezeichnung angegeben werden muss.

Soweit so gut. Jetzt müssen wir nur noch die Schleife umsetzen. Aber wie?! Der engagierte SharePoint-Admin kennt die Thematik wiederkehrender Prozeduren unter dem Begriff “Zeitgeberauftrag“. Hier liegt der Schlüssel zur Lösung unseres Problems. Dort findet genau das statt, was wir erreichen wollen: das wiederholte Auslösen von Prozeduren in einem definierten Rhythmus. Nun benötigen wir noch ein zusätzliches Werkzeug, um die Schleife als Zeitgeberauftrag, verknüpft mit unserem Workflow auszulösen. Dieses Werkzeug heißt HarePoint Workflow Scheduler. Es handelt sich dabei um eine Freeware, die sich leicht über eine Setup.exe auf dem Anwendungsserver installieren lässt. Wichtig ist, dass hierfür ein Konto mit Datenbankzugriff verwendet wird. Mit der Installation wird auf jeder Webseite ein Site-Feature aktiviert, daher kann die Installation in großen Umgebungen durchaus mehrere Stunden dauern.

Nach der Installation navigieren wir zur Webseite, die unsere Aufgabenliste enthält. Wir finden in den Websiteeinstellungen den Eintrag “HarePoint Workflow Scheduler”. Dort hinterlegen wir jetzt unsere heiß ersehnte Schleife.

Der Task-Editor ist aufgebaut wie eine gewöhnliche SharePoint-Liste. Hier wählen wir unseren Workflow aus (wie erwähnt: dieser muss manuell ausführbar sein!). Als nächstes wählen wir die entsprechende Ansicht. Nun legen wir im nächsten Schritt unter “List items” fest, ob der Dauerauftrag für alle Elemente in der Liste oder nur für bestimmte Elemente ausgeführt werden soll. In diesem einfachen Fall soll jeden Abend um 18 Uhr eine entsprechende Mail verschickt werden. Da wir die Bedingungsprüfung mit einer einfachen Konfiguration bereits im Workflow untergebracht haben, lassen wir den Task für jedes Element in der Liste ein mal pro Tag ausführen. Ergibt die erste Bedingungsprüfung im Workflow bei der Überprüfung des Fälligkeitsdatums ein “false”, wird der Workflow umgehend beendet. Daher halten sich Last und Traffic hier in Grenzen.

Für den Fall, dass die Bedingungsprüfung nicht im Workflow, sondern bereits vor der Ausführung des Tasks ausgeführt werden soll, hat man die Möglichkeit, via CAML query eine entsprechende Abfrage zu hinterlegen. Dieses beispielhafte CAML bewirkt, dass der Workflow nur bei Datensätzen ausgelöst wird, die den Status “Nicht begonnen” oder “In Bearbeitung” tragen. In diesem Anwendungsfall sollte die Bedingungsprüfung folgerichtig aus dem Workflow entfernt werden.

 

Im Anschluss an unsere Konfiguration erhalten wir unsere Erinnerungs-Mail. Täglich um 18 Uhr.

Autor: Karsten Ulferts