PortQRY: Ein Hilfsmittel zum AD-Troubleshooting

In verteilten Active Directory-Umgebungen mit mehreren Standorten tauchen regelmäßig immer wieder die folgenden „Klassiker“ unter den gemeldeten Problemen auf:
  • Replikationsstörungen zwischen den Standorten
  • Probleme bei standortübergreifender Namensauflösung (DNS, sowie NetBIOS (WINS))
  • Probleme bei der Anmeldung
  • etc.
Schnell ist man geneigt, in den Eventlogs der beteitilgten Server zu suchen bzw. bekannte Bordmittel wie „DCDiag“, „NetDiag“ oder „Replmon“ zu bemühen. Oft wird man dort auch fündig, gerade wenn es um die Konnektivität zwischen Standorten oder DCs in verschiedenen Subnetzen geht. Woher diese Verbindungsprobleme letztendlich rühren, verraten die Ausgaben dieser Tools aber oft nicht, oder nur „höchst verklausuliert“.

„PortQRY: Ein Hilfsmittel zum AD-Troubleshooting“ weiterlesen

Neues Lizenzmodell für Windows 2016 macht SA-Abschluss jetzt attraktiv

​Gerade macht die Nachricht die Runde, dass Microsoft das Lizenzmodell für Windows Server 2016 verändern wird. Für einige Situationen kann das höhere Preise bedeuten.

Windows Server 2016 wird erst im kommenden Sommer erwartet, mittlerweile gilt die Einschätzung „zweite Jahreshälfte“.

Kunden, die eine aktive Software Assurance (SA) für ihre Serverlizenzen haben, werden ohne Aufpreis auf die neue Version umsteigen können. Dadurch könnte die SA jetzt sehr attraktiv werden, wenn Kunden planen, in absehbarer Zeit auf 2016 zu setzen.

 

Das neue Lizenzmodell für die Serverlizenz wechselt von einer Pro-CPU- zu einer Pro-Core-Lizenzierung. Dabei sind 16 Cores (!) pro Server das Minimum, pro CPU müssen mindestens 8 Cores (!) lizenziert werden. Ergänzende Lizenzen für Server mit höherer CPU-/Core-Ausstattung gibt es dann wohl in Schritten zu je 2 Cores.

Bislang (Windows Server 2012 R2) gelten sowohl die Standard- als auch die Datacenter-Lizenz für je zwei physische CPUs. Diese Zuordnung ändert sich zu den oben angegebenen Cores. Auch weiterhin bleibt es bei einem Server-/CAL-Modell, also werden auch weiterhin zusätzlich CALs für die Endgeräte/Benutzer erforderlich sein.

 

Die Preise für die Core-Packs sollen so definiert sein, dass heute übliche Lizenzkosten nicht überstiegen werden. Wer also bislang eine Standard-Lizenz hat (deckt 2 CPUs ab) und künftig für denselben Servertyp die „kleinste“ Standard-Lizenz für 16 Cores kauft, wird etwa dasselbe bezahlen müssen.

 

Auch weiterhin werden mit der Standard Edition zwei Windows-Server-VMs mitlizenziert sein*, hierbei muss die Lizenz aber alle Cores abdecken, die im Server stecken. Datacenter wird wohl auch künftig „beliebig viele“ VMs lizenzieren. Die Feature-Parität von Standard und Datacenter, die mit 2012/R2 galt, wird wieder verschwinden: Datacenter enthält mit 2016 einige Funktionen, die in Standard fehlen. Dazu zählen leistungsfähige Netzwerk- und Storagetechniken (Storage Replica und die Hyperconverged-Funktion S2D gibt es nur mit Datacenter!).

 

Alle Angaben ohne Gewähr, sie beziehen sich auf ein nicht rechtsverbindliches FAQ-Dokument. Nähere und verlässliche Details sind ohnehin erst zum Marktstart im nächsten Sommer zu erwarten. Wichtig aber noch mal der Hinweis, dass Kunden, die jetzt neue Serverlizenzen für Windows Server 2012 R2 kaufen, noch mal genauer über Software Assurance nachdenken sollten.

 

FAQ: https://t.co/fR2ybzibVx

 

(* Eine VM innerhalb einer VM bei „Nested Virtualization“ zählt als zwei VMs. Wer sowas bauen möchte, wird also von vornherein die Datacenter-Lizenz einplanen müssen.)

MS Office 2010, SharePoint 2010 und System Center 2010 stehen kurz vor ihrem EOL

Das End Of Life für Microsoft Office 2010, SharePoint 2010 und System Center 2010 steht bevor. Es gibt natürlich einen Extended Support, der erst wesentlich später ausläuft, allerdings sollte man auch das „normale“ EOL beachten.

Ein Extended Support unterscheidet sich insofern vom „Standard“, dass viele Support-Features nicht mehr verfügbar sind. Essentielle Dinge wie Sicherheitsupdates werden noch unterstützt, aber Leistungen wie kostenloser Support sind nicht mehr verfügbar. Dafür allerdings der kostenpflichtige. Der Extended Support stellt somit eine „abgespeckte“ Version des Standard Supports dar. Ein Standard Support umfasst alle in der Lizenz enthaltenen Supportdienstleistungen.

Am 13.10.2015 endet der Support der genannten Produkte.

Der Extended Support von Microsoft Office läuft bis zum 13.03.2020 und der von SharePoint 2010 und Systemcenter 2010 bis zum 13.10.2020.

Es gibt natürlich auch Servicepacks, die ein spezifisches Lebensende haben.

  •      Das Microsoft Office 2010 Servicepack 1 hat bereits sein EOL erreicht und
  •      der Microsoft Office 2010 Servicepack 2 Support endet mit dem Produkt zusammen.

Mit dem EOL werden die Produkte abgelöst, um neue Versionen in den Vordergrund zu rücken.

 Hier noch einmal eine konkrete Zusammenfassung aller relevanten Daten:

  •      13.10.2015 Standard-Support-Ende von MS Office 2010, SharePoint 2010 und Systemcenter 2010
  •      13.03.2020 Ende des Extended Supports von MS Office 2010
  •      13.10.2020 Ende des Extended Supports von MS SharePoint 2010 und System Center 2010

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