A PowerShell script to create a chart of Lync response groups

Lync operators and Lync users often need an overview of the response group configuration. This helps them identify how incoming calls are routed between users or mailboxes.

Our company’s trainee Philipp Baar created a PowerShell script that uses the free Graphviz tool to assemble a graphical chart of the Lync response group configuration. The script reads the corresponding data from Lync’s configuration and compiles it into a Graphviz script file. This is then converted into a graphical chart.

 

We published the script to Microsoft’s TechNet Gallery where you can download it for free. Please note that the script comes without any warranty or support.

[TechNet Get-LyncResponseGroupChart: Create a graphical overview of Lync response groups]
https://gallery.technet.microsoft.com/Get-LyncResponseGroupChart-d59e391e

 

WSUS-Updates ab Server 2012 / Windows 8

In Umgebungen, in denen häufig Updates über den WSUS freigegeben werden,​ kann es zu gefühlt willkürlichen Neustarts kommen.

Da sich bei Server 2012 / Windows 8 die Vorgehensweise bei automatischen Updates verändert hat, muss zur Erklärung etwas ausgeholt werden:

  • Server 2012 ohne R2 hat Updates immer im Standardwartungsfenster (03:00 Uhr) installiert, die Einstellungen hinsichtlich Tag/Uhrzeit in der GPO wurden nicht umgesetzt. Dieses Verhalten wurde erst mit Update KB2885694  für Server 2012 ohne R2 behoben. Server 2012 R2 hatte dieses Problem nicht.
  • Server 2012 und Server 2012 R2 führen keinen sofortigen (15 Min.) automatischen Neustart mehr durch, dieser automatische Neustart wird 3 Tage nach der ersten interaktiven Anmeldung nach Installation des Updates durchführt – Microsoft möchte damit Datenverlust durch geöffnete Dokumente minimieren.

Diese beiden Änderungen führen zur Wahrnehmung „Neustart zu einer völlig willkürlichen Zeit“.

Wie begegnet man diesem Problem?

„WSUS-Updates ab Server 2012 / Windows 8“ weiterlesen

Hyper-V-Dokumentation per PowerShell-Skript

Auf der TechNet-Gallery steht jetzt ein PowerShell-Skript namens Get-HyperVInventory.ps1 bereit, mit dem man umfassende Konfigurations-Reports einer Hyper-V-Umgebung erzeugen kann. Diese Berichte dienen der Inventarisierung und bieten einen schnellen, recht vollständigen Überblick über die Virtualisierungsumgebung. Sie enthalten keine Performance-Daten und keine Angaben zum “Gesundheitszustand” der Umgebung. Man kann aber auf Basis der gesammelten Daten einschätzen, ob die jeweilige Umbgebung “sauber” implementiert ist.

„Hyper-V-Dokumentation per PowerShell-Skript“ weiterlesen

Lync 2013 + Autodiscover

​Sollte sich in einem Unternehmen die primäre SMTP-Domäne vom AD-Domänennamen unterscheiden, kann es vorkommen, dass Lync kein Autodiscover hinbekommt und somit nicht auf die Exchange Web Services zugreifen kann. Dies wiederum sorgt dafür, dass im Lync-Client aufgezeichnete Unterhaltungen/verpasste Anrufe/etc. nicht angezeigt werden können.

Lync geht beim Autodiscover grundsätzlich anders vor als der Outlook Client.

Outlook Client Autodiscover Quellen:
1. SCP-Record
2. SRV-Record
3. URLs http(s)://mysmtpdomain.de/autodiscover/autodiscover.xml oder http(s)://autodiscover.mysmtpdomain.de/autodiscover/autodiscover.xml

Lync Client Autodiscover Quellen
1. URLs http(s)://mysmtpdomain.de/autodiscover/autodiscover.xml oder http(s)://autodiscover.mysmtpdomain.de/autodiscover/autodiscover.xml

mysmtpdomain stellt dabei die Domain der primären SMTP-Adresse (Antwortadresse) des angemeldeten Anwenders dar.

Wenn jetzt also die SMTP-Adresse des Anwenders karl@mydomain.de lautet, aber die Autodiscoverkonfiguration samt SCP/SRV/DNS-Einträgen auf exchange.intranet.mydomain.de hört, wird der Lync-Client kein Autodiscover durchführen können.

Die pragmatischte Lösung wäre wohl eine DNS-Zone für mydomain.de anzulegen und dann den entsprechenden Eintrag autodiscover.mydomain.de zu ergänzen – so gelingt dann auch Karl das Lync-Autodiscover. 😉

P.S.: Darauf achten, dass ein gültiges Zertifikat für autodiscover.mydomain.de vorhanden ist!

AD-Cleanup: adminSDHolder

Im Rahmen der AD-Administration kommt es immer wieder vor, dass Accounts nicht vom Service-Desk oder anderen technischen Mitarbeitern administriert werden können, trotzdem der Account in einer OU liegt, die durch den Administrator verwaltet werden kann. Die Ursache dafür ist häufig, dass diese Accounts einmal Mitglied der geschützten Gruppen waren (Domain Admins, Enterprise Admins, Account Operators, …) oder es noch sind.

Für diese Gruppen gibt es einen besonderen Sicherungsmechanismus, den sogenannten „adminSDHolder“. Dieser Mechanismus sorgt dafür, dass Accounts die direkt oder mittels Verschachtelungen Mitglied dieser Gruppen sind, eine Vererbungsunterbrechung erfahren. Für sie gelten die Berechtigungen, welche auf der OU „adminSDHolder“ hinterlegt wurden. Weiterhin wird für diese Accounts das AD-Attribut „adminCount“ auf „1“ gesetzt(auf diesem Wege kann man sie auch über eine LDAP-Query recht simpel identifizieren). Die OU „adminSDHolder“ enthält selbst keine Objekte, sondern dient einfach nur als Aufhänger für die Berechtigungssteuerung der geschützten Objekte (Pfad: \\my.domain\System\adminSDHolder).

Diese Zuordnung erfolgt automatisch und wird standardmäßig alle 60 Minuten überprüft. Dabei ist es egal wo der Account im AD liegt. Leider wird diese Zuordnung nicht aufgehoben, wenn man aus den entsprechenden Gruppen entfernt wird. Für diesen Zweck empfiehlt es sich einen Prozess zu schaffen oder eine Automatisierung bspw. mittels eines Scripts. Den Scriptansatz habe ich kürzlich einfach mal umgesetzt und als Scheduled Task etabliert.

Das Script setzt das Attribut “adminCount” zurück und stellt die Berechtigungsvererbung für sämtliche AD-Objekte (User, Gruppe) wieder her, die nicht mehr Mitglied der geschützten Gruppen sind und das Attribut „adminCount“ auf „1“ gesetzt haben. Anschließend lässt sich der Account wieder entsprechend den Berechtigungen der OU, in der er sich befindet, verwalten und wie jeder normale Account behandeln.

Kurze Anmerkung:

Derzeit ist das Script noch gegen ein versehentliches Schreiben geschützt. Für einen schreibenden Durchlauf bitte die Variable $just_logging auf $false setzen.

Weiterhin wird eine Logdatei geschrieben, derzeit im Ausführungspfad – sollte für Scheduled Tasks auf einen entsprechenden Ordner gesetzt werden. Dazu die Variable $logpath auf den entsprechenden Wert setzen.

Skript: remove_from_adminSDHolder

Weiterführende Infos unter:

http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx

AD-Accounts mit geänderter primärer Gruppe

Die Möglichkeit zur Änderung der primären Gruppenmitgliedschaft eines AD-Accounts hat vor allem historische Hintergründe. Im alltäglichen Betrieb abseits ins AD integrierter Apple-Maschinen/-Services oder Posix kompatibler Anwendungen ist es nicht notwendig diese Einstellung zu verändern.

Zu finden ist sie über die „Active Directory Users and Computers“-Konsole im MemberOf-Tab unter der Gruppenübersicht und den zugehörigen Buttons.

Ein großer Nachteil der Änderung der primären Gruppe liegt darin, dass man bspw. die Mitgliedschaft nicht offen einsehen kann und diese in den herkömmlichen Abfragen häufig nicht auftaucht, da diese über das AD-Attribut primaryGroupID (enthält die RID der betreffenden Gruppe) gehandhabt wird und nicht über den üblichen Weg in dem auch über die GUI einsehbaren Attribut „memberOf„.

Wenn man nun befürchtet oder direkt feststellt, dass diese Einstellung nicht überall gegeben ist, kann man über das folgende LDAP-Query gezielt danach suchen:

„(&(objectClass=user)(objectCategory=person)(!primaryGroupID=513))“

Alternativ per Powershell mittels:

Get-ADUser -Filter { primaryGroupID -ne „513 } -Properties primaryGroupID

Hat man erst einmal eine Liste der betroffenen User, ist natürlich spannend, um welche Gruppe es sich jeweils handelt um die weiteren Zusammenhänge zu erörtern. Dazu habe ich mir kurzerhand ein Script geschrieben, dass ich kurz vorstellen und publizieren möchte.

Gesucht wird mittels des oben beschriebenen Statements, anschließend wird die primaryGroupID der betroffenen Accounts in den jeweiligen Gruppennamen aufgelöst. Dazu ist entscheidend, dass das Attribut in dem diese Einstellung auf dem Gruppen-Objekt gespeichert wird primaryGroupToken heißt und nicht direkt danach gesucht werden kann. Diesen Umstand verdanken wir der Eigenschaft des Attributs als „computed“ (berechnet). Das Attribut wird bei jedem Abruf aus der ObjectSID errechnet und folglich nicht die ganze Zeit vorgehalten. Dies lässt sich bspw. dadurch umgehen, dass man erst alle Gruppen samt diesem Attribut einzeln lädt und anschließend nach der gewünschten ID filtert.

Skript: Get-UserswithdiffprimGroupID

Weiterführende Links:

Derzeit basiert das Script auf den seit 2008 R2 mitgelieferten AD-Modulen für die Powershell, welche auf jedem neueren DC ohnehin installiert sein sollten. Für eine Nutzung in einem 2003er/2008er Umfeld müssten die AD-WebServices (AD Management Gateway Service) installiert werden und ein Client mit den installierten AD-Modulen verwendet werden:

http://www.microsoft.com/de-de/download/details.aspx?id=2852

Clientseite:

http://blogs.msdn.com/b/rkramesh/archive/2012/01/17/how-to-add-active-directory-module-in-powershell-in-windows-7.aspx

MS15-014: Vulnerability in Group Policy could allow security feature bypass: February 10, 2015

Bitte auch folgenden Artikel beachten:
MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015

Problembeschreibung:
Ein Angreifer kann das „Group Policy Security Configuration Engine policy file“ auf einem Zielsystem über eine „man-in-the-middle attack“ in einen inkonsistenten Zustand versetzen.

Dies führt dazu, dass sämtliche Sicherheitseinstellungen auf möglicherweise weniger sichere Standardwerte zurückgesetzt werden. Bspw. könnten die in MS15-011 eingeführten Sicherheitsfeatures umgangen werden.

Maßnahme:
Der Patch KB3004361 für alle Clients ab Windows Vista und Serversysteme ab Windows Server 2003 ändert das Verhalten bei der Anwendung von Gruppenrichtlinien. Anstatt in einem Fallback-Szenario die Standardwerte zu laden, werden die letzten erfolgreich angewendeten Werte genutzt.

Einschätzung:
Die Installation des KB3004361 sollte zeitnah erfolgen, mit Funktionsbeeinträchtigungen ist nicht zu rechnen.

Installationsanweisungen:
Zur Behebung der Lücke ist es notwendig das per Windows Update bereitstehende Update KB3004361 auf allen Clients und Servern einzuspielen.

MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015

Problembeschreibung:
Die Security Configuration Engine verarbeitet Gruppenrichtlinien, Herkunft und Integrität der GPOs werden dabei nicht überprüft. Durch Manipulation auf Netzwerkebene ist es möglich die Zugriff auf Sysvol-/Netlogon-Verzeichnisse umzuleiten und somit Clients/Servern andere GPOs unterzuschieben.

Dadurch kann Schadcode unbemerkt eingeschleust werden.

Maßnahme:
Der Patch KB3000483 für alle Clients ab Windows Vista und Serversysteme ab Windows Server 2008 führt das Feature „UNC Hardened Access“ ein. Dadurch wird eine gegenseitige Authentifizierung von Client und Server (Mutual Authentication) sowie das signieren von SMB-Traffic ermöglicht.

Eine Gruppenrichtlinie steuert die Aktivierung des Features „UNC Hardened Access“ für bestimmte Pfade nach Bedarf.
„MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015“ weiterlesen

End of Support für Windows Server 2003: Sind Sie bereit?

Der 14. Juli ist nicht nur französischer Nationalfeiertag, sondern in diesem Jahr auch für die IT bedeutsam. Denn an diesem Tag endet der Support für Windows Server 2003.

Im vergangenen Jahr hat Microsoft den Support für Windows XP endgültig eingestellt. Für den „großen Bruder“ des Client-Windows tritt im Juli dasselbe Schicksal ein: Es wird dann keine Updates, keine Security-Fixes und keine Unterstützung mehr geben.

Windows Server 2003 war ein sehr beliebtes Server-Betriebssystem, und in einigen Unternehmen ist es das immer noch. Setzen Sie Windows Server 2003 noch ein? Dann lautet unsere Empfehlung, jetzt zügig auf eine aktuellere Windows-Version umzusteigen. Denn die Erfahrung mit Windows XP zeigt, dass nicht nur die Angriffe auf das veraltete System schnell zunehmen werden. Auch das Know-how im Markt schwindet schnell, sodass auch Drittanbieter oft keine Fragen mehr dazu beantworten können.

Wir stehen an Ihrer Seite: Unsere Systems Engineers analysieren mit Ihnen die Systeme in Ihrem Netzwerk und entwickeln einen Plan zum Umstieg. Dabei nehmen wir auch gern Kontakt zu den Herstellern Ihrer Fachapplikationen auf, um deren Empfehlungen für die Migration aufzunehmen.

Oder Sie kommen zu uns: Am 28. April 2015 laden wir Sie und Ihre Kollegen aus anderen Unternehmen zu einem „Chalk Talk“ ein. Gemeinsam mit Consultants aus unserem Haus diskutieren Sie anhand konkreter Beispiele, wie ein Umstieg von Windows Server 2003 auf ein aktuelles System aussehen kann. Ob Active Directory, Exchange oder Applikationsserver – eine technische Diskussion, die sicher viele gute Ideen erzeugt.

Die Teilnehmerzahl ist begrenzt, daher bitten wir um Ihre Anmeldung.

Wir freuen uns, mit Ihnen ins Gespräch zu kommen! Als kleinen zusätzlichen Service finden Sie im Anhang dieses Artikels auch noch eine Übersicht über die Support-Daten weiterer Microsoft-Systeme. So können Sie schon für die Zukunft vorplanen.

Kontakt: Nils Kaczenski, Teamleiter Microsoft-Consulting

Support-Daten für wichtige Microsoft-Produkte