Kürzlich hatte ich ein ärgerliches Problem mit einem Setup für Hyper-V Replica. Eigentlich kann man bei dem Feature fast nichts falsch machen. Darum nervte mich das Problem auch besonders.

Wie immer, wenn man der Meinung ist, dass man das System eigentlich gut kennt, stößt man selbst natürlich auf die Situationen, in denen es nicht mal ordentliche Fehlermeldungen gibt. So auch hier: Beim Versuch, die Replikation für eine VM einzuschalten, meldete Hyper-V ganz am Ende (aber sofort nach dem Klick auf “Fertig stellen”):

Fehler beim Aktivieren der Replikation für den virtuellen Computer „MSC-Blanko": Die Serververbindung konnte nicht hergestellt werden. (0x00002EFD). (ID des virtuellen Computers: 8CCFC631-4A0C-4454-8315-xxxyyyzzz)

Mit dem angegebenen Replikatserver „msc-hvreplica01.MSC.Demo" kann keine Verbindung hergestellt werden. Fehler: Die Serververbindung konnte nicht hergestellt werden. (0x00002EFD). Vergewissern Sie sich, dass der angegebene Server als Replikatserver konfiguriert ist, dass eingehende Verbindungen am Port „80" zugelassen werden und dass das gleiche Authentifizierungsschema unterstützt wird.

Wie sich herausstellte, gibt es zu der Fehlernummer 0x00002EFD nicht nur keine brauchbaren Fundstellen im Web. Nein, tatsächlich handelt es sich um einen Fehlercode, der allgemeiner kaum sein kann – er sagt nicht viel mehr aus als “ich kann keine Verbindung zur anderen Seite aufbauen und weiß nicht warum”.

Die Firewall war nicht Schuld. Tatsächlich hätte das die Ursache sein können, aber Hyper-V weist schon beim Einrichten der Replica-Server darauf hin, dass man eine entsprechende Ausnahme setzen muss. In der Windows-Firewall ist das dann auch sehr einfach, denn es gibt zwei fertige Regeln, die schon “Hyper-V Replikation” im Namen tragen und die man nur anschalten muss. Diese Regeln tun auch nichts weiter, als eingehenden TCP-Traffic auf Port 80 bzw. 443 zuzulassen – auch bekannt als HTTP bzw. HTTPS. Nur um sicherzugehen, schaltete ich die Firewall testweise ganz ab, das Problem blieb. OK, also Firewall wieder an.

Auch die Authentifizierung war nicht das Problem: Beide Hosts gehören derselben Domäne an, ich war auch auf beiden mit demselben Adminkonto angemeldet, um die Replikationsbeziehung einzurichten. Das AD arbeitete, wie es soll, IP-Adressen und DNS-Namensauflösung waren korrekt. Ein Zugriff per Telnet auf Port 80 auf dem “empfangenden” Host ergab, dass dieser antwortet und auch (anscheinend korrekte) HTTP-Antworten gibt.

Nur zur Vorsicht alle Server nacheinander neu gestartet (und wo nötig gleich fehlende Updates installiert) – keine Änderung.

Gut. Oder vielmehr: Nicht gut. Ich versuchte, dem System Genaueres zu entlocken. Dazu schaltete ich auf beiden Seiten das Analytic Log für den Hyper-V-Managementdienst ein. Das geht so:

• Ereignisanzeige starten.
• Im Menü “Ansicht” einschalten: “Analytische und Debugprotokolle einblenden”.
• Navigieren zum Zweig: Anwendungs- und Dienstprotokolle / Microsoft / Windows / Hyper-V VMMS. Dort gibt es nun ein Protokoll namens “Analytic”. Hierauf rechtsklicken und auswählen: “Protokoll aktivieren”.

Wichtig: Die Analytic and Debug Logs arbeiten anders als die normalen Eventlogs. Sie sammeln nur Daten, wenn man sie aktiviert, zeigen währenddessen aber nichts an. Erst wenn man sie deaktiviert, sieht man die gesammelten Daten. Das liegt daran, dass diese Logs schnell sehr viele Daten produzieren, sodass man sie nur sammeln lässt, wenn man konkrete Tests ausführt. Niemals “einfach so” aktiviert lassen!

• Dasselbe auf dem anderen Server wiederholen.
• Nun den fehlerhaften Vorgang ausführen, hier also: Versuchen, die Replikation für eine VM einzurichten.
• Nachdem der Fehler aufgetreten ist: Auf beiden Seiten Rechtsklick auf das Protokoll “Analytic” und auswählen “Protokoll deaktivieren”.
• Nun sollte das Protokoll seine Daten anzeigen. Zeigt es nichts, dann gab es nichts zu sammeln. In meinem Fall sah ich auf dem “sendenden” Host einige Einträge, auf dem “empfangenden” keine. Schon hier also ein Beleg, dass beim Empfänger überhaupt nichts ankommt.

In den ausführlichen Protokollen fand ich gleich zu Beginn interessante Einträge:

[FrnHttpClient::SetupConnection (frnhttpclient.cpp:247)] Send Request (GET) failed: unknown error (0x80072efd)

Das klingt, als würde tatsächlich schon der erste Versuch fehlschlagen, per HTTP eine Verbindung zur Gegenseite aufzubauen. Zur Überprüfung schlug ich den Fehlercode 0x80072efd nach – hier hilft das kleine Tool err.exe, das sich bei Microsoft herunterladen lässt (es nennt sich zwar “Exchange Server Error Code Look-up”, hat aber eigentlich mit Exchange nichts zu tun):

[Download Microsoft Exchange Server Error Code Look-up from Official Microsoft Download Center]
https://www.microsoft.com/en-us/download/details.aspx?id=985

Der Aufruf “err.exe 0x80072efd” ergab allerdings nichts wirklich Neues: “ERROR_INTERNET_CANNOT_CONNECT” – gut, das wusste ich mittlerweile.

Wenn aber die Netzwerkverbindung funktioniert, die Anmeldung auch, und sogar per Telnet der angefragte Port anscheinend korrekt erreichbar ist – was könnte dann noch dazwischenfunken?

Auf so eine Frage gibt es immer einen Generalverdächtigen: Der Virenscanner. Tatsächlich lief auf beiden Seiten ein solcher, das konkrete Produkt tut hier nichts zur Sache.

Also den Virenscanner auf der “Empfangsseite” abgeschaltet (naja, in Wirklichkeit: abgeschossen, denn auf dem normalen Weg wollte er sich nicht abschalten lassen). Ergebnis: Geht immer noch nicht.

Eigentlich nur noch versuchshalber den Virenscanner auch auf der “Senderseite” abgeschossen: Siehe da, plötzlich ging’s, und die Replikation ließ sich einrichten.

Fazit

Am Ende bleibt die Erkenntnis: Wenn man einen Virenscanner auf einem Server einsetzt, dann muss man ihn auch richtig konfigurieren. Und man muss auf die Idee kommen, dass der Virenscanner überhaupt beteiligt sein könnte. Was auch immer das Ding getan hat – zum Zeitpunkt des Fehlers waren keine Dateien beteiligt, sondern es schlug ein Client-HTTP-Zugriff fehl. Anscheinend hielt der Scanner es für eine gute Idee, dort einzugreifen – war aber keine gute Idee.

Daneben habe ich hier einige Hilfsmittel gezeigt, unspezifischen Fehlern doch noch auf die Spur zu kommen.

Und, ganz wichtig: Wenn man eine Änderung versucht hat und diese nichts bringt, dann sollte man diese wieder rückgängig machen (in meinem Beispiel etwa: die abgeschaltete Firewall wieder einschalten) – es sei denn, man ist sich sicher, dass man diese Änderung beibehalten will und dokumentiert dies auch.

Eric Siron hat sich in einer sehr lesenswerten Artikelreihe auf dem Altaro-Blog zu Hyper-V einer Komponente von Hyper-V angenommen, die nahezu unbekannt ist. Die Rede ist von dem Integrationsdienst “Datenaustausch”, im Original auch bekannt als “Key/Value Pair Exchange”.

Anders als oft vermutet wird, sorgt dieser Dienst nicht für eine Integration der Zwischenablage zwischen Host und VM, und er sorgt auch nicht für Drag-and-Drop-Funktionen, wie man sie aus Desktop-Virtualisierern kennt. Tatsächlich kann der Dienst nur einzelne Werte über die Registry einer VM austauschen. Dass dies durchaus nützlich sein kann, stellt Eric anhand einiger Hintergründe und Beispiele dar.

[Hyper-V Key-Value Pair Data Exchange Part 1: Explanation]
http://www.altaro.com/hyper-v/hyper-v-key-value-pair-data-exchange-part-1-explanation/

[Hyper-V Key-Value Pair Data Exchange Part 2]
http://www.altaro.com/hyper-v/hyper-v-key-value-pair-data-exchange-part-2-implementation/

Mit Windows 10 und der Möglichkeit der zentralen Verwaltung von Sideloaded Apps erhält der Windows Store eine spannende Rolle im Enterprise-Kontext. Zwar wurde der Store bereits mit Windows 8 in das Betriebssystem implementiert, die Anwendungsszenarien blieben jedoch aus und so wurde er in Unternehmen meistens deaktiviert. Die Herausforderung, der konsolidierten Plattform Windows 10 Apps über alle Devices zur Verfügung zu stellen, eröffnet neue Möglichkeiten. Im aktuellen Blogartikel beschreiben wir die Vorgehensweise der Konfiguration, stellen den Unterschied zwischen online und offline lizenzierten Apps heraus und gehen auf die Implementierung des Windows Store for Business ein. Auch die Varianten der App-Bereitstellung werden thematisiert.

[Windows 10 Enterprise Serie – Windows Business Store | sepago]
https://www.sepago.de/blog/2016/02/18/windows-10-enterprise-serie-windows-business-store

Bei traditionellen Deployments von Betriebssystemen wird das Image entweder bereits vor seiner Verteilung durch den Administrator angepasst oder im Rahmen eines automatisierten OS-Deployments zum Zeitpunkt der Verteilung konfiguriert. Im Nachhinein gewünschte Änderungen an Kernkomponenten des Betriebssystems führen in den meisten Fällen zu einem Neuaufsetzen (Wipe and Load) des Gerätes.

Mit Windows 10 können Bereitstellungspakete erstellt werden, die das schnelle und effiziente Konfigurieren eines Geräts ermöglichen, ohne ein neues OS Image installieren zu müssen. Provisioning packages sind so einfach aufgebaut, dass Benutzer ohne technischen Hintergrund nur wenige Klicks durchführen müssen, um ihr Gerät unternehmenskonform zu konfigurieren. Das kann zum Beispiel das Anlegen weiterer Benutzer, die Installation von Programmen oder die Konfiguration von Windows sein.

Hier geht's lang zum Blogpost:

[Windows 10 Enterprise Serie – Windows Provisioning | sepago]
https://www.sepago.de/blog/2016/02/26/windows-enterprise-serie-windows-provisioning

Dieser Artikel erschien zuerst auf dem Blog Consulting-Lounge.de.

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”.

Der Verdacht liegt meist nahe, dass die Ursachen im Bereich Netzwerk oder Firewall-Regeln zu suchen sind. Auf Nachfrage in den entsprechenden Abteilungen heißt es dann oft sinngemäß: “Nein, an der Firewall haben wir nichts geblockt, LDAP / AD sind freigegeben” oder so ähnlich. Ich selbst z.B. war in solchen Situationen als “Windows-Mensch” oft in der Beweispflicht.

Hier kommt ein sehr nützliches (wenn auch altes) Tool von Microsoft ins Spiel: PortQRY. Es handelt sich hierbei um einen simplen PortScanner, welcher allerdings gewisse “Scan-Templates” für bestimmte Dienste, wie z.B. “Domains and Trusts” mitbringt.

Da zu einer erfolgreichen Kommunikation im AD bzw. zwischen DCs weitaus mehr nötig ist als “LDAP” und man die benötigten TCP- bzw. UDP-Ports ggf. nicht immer im Kopf hat, bietet das Tool eine komfortable schnelle Möglichkeit, die Protokoll-Endpunkte zwischen zwei DC´s auf “Durchlässigkeit” zu prüfen. Ursprünglich handelt sich um ein reines Kommandozeilen-Tool, es existiert allerdings bereits seit langem auch eine GUI dafür, welche keiner Installation bedarf und hier heruntergeladen werden kann:

https://www.microsoft.com/en-us/download/details.aspx?id=24009​

Sobald das Tool (z.B. auf einem DC) gestartet ist, kann man sich wie in folgendem Beispiel einmal die vorgefertigten “Services” anschauen, welche in XML-Beschreibungen definiert sind und zeigen welche Ports dabei gescannt werden:

Dieses Bild zeigt den Auszug eines “Beispiel-Output” eines Query von DC zu DC zwischen zwei Standorten:

Man muss beim Auswerten des Outputs natürlich im Hinterkopf behalten, dass es sich bei UDP um ein “verbindungsloses” Protokoll handelt. Die Ergebnisse müssen für UDP nicht aussagekräftig sein. Einem “FILTERED” oder “NOT LISTENING” für TCP basierte Queries sollte man allerdings auf den Grund gehen, denn hier könnte eine Firewall den Zugriff verhindern, oder es gibt mit dem Dienst auf dem Zielsystem ein anderweitiges Problem.

Zur Interpretation des Output siehe auch:

https://technet.microsoft.com/en-us/library/cc759580%28v=ws.10%29.aspx​

Neulich fiel mir auf einem Windows Server 2012 R2 folgende Warnung in der Ereignisanzeige des Anwendungsprotokolls auf:

"Fehler bei der Installation des Kaufnachweises aus der ACPI-Tabelle. Fehlercode: 0xC004F057"
Quelle: Security-SPP
Ereignis-ID: 1058

Der Server wurde mit Windows Server 2012 R2 als OEM ausgeliefert. Da ich generell vorinstallierte Server mit Betriebssystem nicht mag, weil man nie weiß was der Hersteller da noch so installiert, installierte ich den Server selber von Hand neu.

Natürlich dachte ich sofort an die Aktivierung, vermutlich war diese noch nicht geschehen. Der Server-Manager zeigte jedoch, dass die Installation aktiviert war.

Nach der erneuten Eingabe des OEM-Produktschlüssels war die Installation immer noch aktiviert, aber die Warung in der Ereignisanzeige war verschwunden.

Credential Guard nutzt (genau wie das Windows-10-Feature Device Guard) eine neue Komponente des Betriebssystems, genannt „Virtualization-based Security“. Diese Komponente stellt im Betriebssystem über die Virtualisierungstechnik eine stark gesicherte Ebene bereit.

Auf dieser Ebene werden bei aktiviertem Credential Guard „Secrets“ (Passworthashes, Kerberos Tickets) abgelegt. Diese sind isoliert vom Rest des Betriebssystems und somit deutlich besser geschützt als in vergangenen Windows Versionen.

Näheres darüber findet sich in diesem Blogpost:

[Windows 10 Enterprise Serie: Schütze deine Credentials – Credential Guard – sepago.de]
https://www.sepago.de/blog/2016/03/17/windows-10-enterprise-serie-schuetze-deine-credentials-credential-guard

Microsoft, das Bundeskriminalamt (BKA) und das Bundesinnenministerium haben bestätigt, dass der neue “Bundestrojaner” auch als reguläres Windows-Update verbreitet werden wird. Hierüber hatte es Spekulationen gegeben, nachdem vor Kurzem bekannt geworden war, dass der “Bundestrojaner 2.0” kurz vor der Genehmigung steht.

Zu diesem überraschenden Schritt haben die Behörden und der Softwarehersteller ausdrücklich aufgrund der Auseinandersetzung von Apple und dem FBI in den USA entschlossen. “Apple hat völlig Recht, sich gegen die Anordnung zum Knacken seiner eigenen Verschlüsselung zu sperren”, betonte Claudia Porta, Sicherheitsexpertin bei Microsoft Deutschland. “Der ganze Rechtsstreit war ja nur nötig geworden, weil das FBI keinen legalen Weg hatte, an die Daten zu kommen. Dies umgehen wir, wenn der Bundestrojaner als regulärer Teil von Windows implementiert ist.” Das sei im Prinzip nichts anderes als das, was Apple sonst auch in den USA praktiziere: “Bislang hat Apple den Behörden entschlüsselte Kundendaten übergeben, ohne mit der Wimper zu zucken”, so Porta. In diesen Fällen habe ohnehin eine Schnittstelle für den Staat vorgelegen. Nur im letzten Fall, der nun solche Wogen schlage, sein das nicht so gewesen. “Das hätte man ja auch eleganter machen können. So wie wir jetzt”, kann sich die Microsoft-Mitarbeiterin einen Seitenhieb nicht verkneifen.

Aus Sicht des BKA und des Innenministeriums umgeht das Trojaner-Update für Windows auch eine rechtliche Hürde: “Eigentlich kann man so gar nicht mehr von einem Trojaner sprechen”, so BKA-Sprecher Lothar Irpa. Ein herkömmlicher Trojaner müsse gegen den Willen des Anwenders eine Hintertür öffnen, was juristisch nicht immer ganz einfach sei. “In unserem Fall müssen wir dem Anwender nichts mehr unterjubeln, denn es ist ja schon längst da.” Normale Anwender müssten von der BKA-Software nichts befürchten: “Wir aktivieren sie nur gegenüber Kriminellen”, beruhigt die Staatssekretärin im Innenministerium Hella Mertniss. Damit sei dies auch kein Fall für die Datenschützer, denn es würden keine Daten unbescholtener Personen übertragen.

Sicherheitsspezialisten rechnen damit, dass das Windows-Update mit der Nummer 16040114, das den Bundestrojaner 2.0 enthält, schon am nächsten Patchday, also noch im April, ausgerollt wird. Alle aktuellen Windows-Versionen werden damit versorgt.

Bisher war die Bewertung der Clientsysteme bezüglich ihrer Kompatibilität für eine erfolgreiche Windows-10-Migration nur durch manuelle Abfragen über den Configuration Manager möglich. Man konnte z.B. über selbst definierte Reports oder Queries die Kompatibilitätschwellenwerte abfragen.

Microsoft hat sich dieses Themas angenommen und hat am 24.03.16 ein neues Tool hierfür veröffentlicht.

Mit dem „ConfigMgr Upgrade Assessment Tool“ ist es nun möglich, diese Abfragen out of the box auf einem Configuration Manager Site Server zu installieren. Das Tool erstellt Reports, welche auf den aktuellen Anforderungen von Windows 10 basieren.

Hier geht's zum Blogpost:

https://www.sepago.de/blog/2016/03/31/kompatibilitaetspruefung-fuer-die-migration-auf-windows-10-mit-dem-configmgr-upgrade

Der Softwarehersteller Altaro stellt ein kostenloses E-Book zu Monitoring und Optimierung der Performance von Hyper-V-Systemen bereit. Autor Paul Schnackenburg stellt dabei in kompakter Form einige Bordmittel, Tools und Hintergründe zum Thema vor. Das E-Book wendet sich vor allem an “gestresste” Admins, die keine langen Abhandlungen suchen, sondern einen schnellen Einstieg.

Hier geht’s lang:

[Supercharging Hyper-V Performance – Optimizing Hyper-V Host]
http://www.altaro.com/hyper-v-backup/ebook/supercharging-hyper-v-performance-ebook.php

Kürzlich richtete ich einen Heimrechner unter Windows 10 ein. Nach getaner Arbeit wollte ich das vordefinierte Konto zum Standardbenutzer herabstufen, weil es das Hauptkonto des Rechners sein sollte. Zuvor hatte ich natürlich einen separaten Administrator angelegt.

Dieses Herabstufen kann man über die PC-Einstellungen vornehmen.

Nach Abschluss der Arbeiten startete ich den Rechner neu. Das Konto des Hauptbenutzers wurde nicht mehr zum Anmelden angezeigt – nur der separate Administrator konnte sich noch einloggen.

Nanu? Was war geschehen?

Wie sich herausstellte, hatte Windows beim Herunterstufen des Kontos ganze Arbeit geleistet – oder eben nicht. Das Benutzerkonto war in keiner Gruppe mehr Mitglied, auch nicht in der Gruppe “Benutzer”. Nur mit dieser Mitgliedschaft hätte es sich aber anmelden dürfen.

Mit dieser Erkenntnis war die Lösung einfach: Das Konto in die Gruppe “Benutzer” aufnehmen. Unklar – und ärgerlich – bleibt aber, warum das Konto überhaupt nicht in der Gruppe war …

Scott Hanselmann hat in einem lesenswerten Blogbeitrag die Frage beantwortet, ob und wie SSDs unter Windows defragmentiert werden und ob und wann das nötig ist. Der Beitrag ist schon etwas älter, stellt die Hintergründe aber sehr gut dar und korrigiert einige Missverständnisse.

[The real and complete story – Does Windows defragment your SSD? – Scott Hanselman]
http://www.hanselman.com/blog/TheRealAndCompleteStoryDoesWindowsDefragmentYourSSD.aspx

In unserem Webinar am 19. Mai 2016 erfahren Sie alles rund um Deployment-Verfahren für Windows 10 im Enterprise-Umfeld. Wir zeigen Ihnen die Neuigkeiten im Windows-10-Deployment-Prozess, welche Chancen ein Inplace-Upgrade bietet und was aus dem klassischen „Wipe and Load“-Verfahren wurde. Ein weiterer Schwerpunkt des Webinars sind Windows-10-„Provisioning Packages“. Lernen Sie potentielle Einsatzszenarien kennen und informieren Sie sich über die Vor- und Nachteile.

Agenda

• Vorstellung Speaker
• Was ist neu im Windows-10-Deployment-Prozess?
• Kompatibilität Assessment Readiness (MAP)
• Abhängigkeit zu Internet Explorer 11
• Welche Chancen bietet Inplace Upgrade?
  • Welche Einsatzszenarien gibt es?
  • Welche Einschränkungen gibt es?
  • Demo
• Was wurde aus Wipe and Load?
• Was kommt mit Windows-10-Provisioning-Packages?
  • Einsatzszenarien
  • Vor- und Nachteile
  • Demo
• Deployment Best Practices
• Windows 10 Reporting und Automatisierungsansätze
• Q & A

Hier gehts zur Anmeldung: https://attendee.gotowebinar.co m/register/4648891666324217603?splash=false

Mit Windows Server 2016 erfüllt Hyper-V endlich einen lang gehegten Wunsch vieler Virtualisierungs-Admins: Künftig wird Hyper-V die “Nested Virtualization” beherrschen. Damit ist es möglich, einen Virtualisierungs-Host selbst als VM einzurichten, sodass eine VM in einer VM auf einem Host laufen kann. VMwares Produkte können dies schon seit vielen Jahren.

Bislang hatte Microsoft sich geweigert, dieses Feature zu implementieren, weil es dafür eigentlich keinen “ernnsthaften” Nutzen gibt (bzw. gab). Eine VM in einer VM wird nie besonders schnell laufen, und auch die Stabilität kann durchaus eingeschränkt sein. Wer diese Funktion haben wollte, hatte meistens auch Test- oder Demo-Systeme im Sinn.

Durch die neue Container-Technik in Windows Server 2016 ändert sich das Spiel. Ein Mehrwert, den Microsoft dieser Technik hinzufügt, sind besonders isolierte Container, die ihrerseits als Rumpf-VMs in Hyper-V laufen. Damit dies auch in Hosting- und Cloud-Szenarien sinnvoll skalierbar wird, sollten dabei die Container-Hosts ihrerseits auch als virtuelle Maschinen laufen können. Also: Nested Virtualization.

Offiziell wird das natürlich nur für Hyper-V unterstützt werden, vielleicht sogar ausschließlich für Hyper-V-Container. Doch die Technik ist da, und sie funktioniert auch recht umfassend. So war es nur eine Frage der Zeit, bis jemand probiert, einen vSphere-Host als VM unter Hyper-V zu betreiben.

Und das ist auch geschehen. Der folgende Artikel beschreibt, wie es im aktuellen Stand der Technik funktionieren kann.

[Install a VMWare ESXi 6.0 Hypervisor in a Hyper-V VM | PowerShell, Programming and DevOps]
https://dscottraynsford.wordpress.com/2016/04/22/install-a-vmware-esxi-6-0-hypervisor-in-a-hyper-v-vm/

Der Sicherheitsexperte @subTee hat herausgefunden, wie man AppLocker mit einem einfachen Trick umgehen kann. Dadurch wird der Schutz vor “bösen” Applikationen in einigen Situationen wirkungslos.

Die Ursache liegt in dem Konstruktionsprinzip von AppLocker, das bestimmte Systemkomponenten niemals einschränkt. Dazu zählt auch regsvr32.exe – dieses Programm nutzt man normalerweise, um DLLs und andere Komponenten im System zu registrieren. Das Programm hat die wenig bekannte Eigenschaft, dass es nahezu beliebige Pfade zu den Komponenten akzeptiert – und dass es diese bei bestimmten Aufrufen einmal komplett ausführt. Das Ganze funktioniert auch mit Skripten aus dem Internet – und als normaler Benutzer ohne Adminrechte …

[subTee: Bypass Application Whitelisting Script Protections – Regsvr32.exe & COM Scriptlets (.sct files)]
http://subt0x10.blogspot.de/2016/04/bypass-application-whitelisting-script.html

Microsoft hat gerade bekannt gegeben, dass das nächste große Update für Windows 10 am 2. August bereitgestellt wird. Das bezieht sich üblicherweise auf Redmond-Zeit, hier also frühestens am Nachmittag. Danach wird es aber sicher noch dauern, bis der Download weltweit verfügbar ist.

Das Update kommt damit wenige Tage nach dem Ende des “Free Upgrade Offer”, welches am 29. Juli 2016 endet. Wer noch kostenlos aktualisieren möchte, sollte das rechtzeitig vorher tun, denn es lässt sich nicht genau sagen, wann Microsoft die Aktivierungsserver abschaltet.

[Windows 10 Anniversary Update Available August 2 | Windows Experience Blog]
https://blogs.windows.com/windowsexperience/2016/06/29/windows-10-anniversary-update-available-august-2/

Viele spannende Infos gab es dieser Tage auf der World Partner Konferenz in Toronto, Canada.

Eine der wichtigsten Informationen war die Ankündigung zum Release von Windows Server 2016 undSystem Center 2016 im Zeitraum der Konferenz "Ignite" im September diesen Jahres.

Windows Server 2016 wird es zukünftig in den drei Versionen geben:

• Datacenter
• Standard
• Essentials

Anders als bei Windows Server 2012/R2 werden die Funktionen von Standard und Datacenter wohl nicht mehr identisch sein. Die Essentials-Fassung soll ihren Haupteinsatz bei Unternehmen mit weniger als 50 Usern finden.

Darüber hinaus ist schon länger bekannt, dass es drei Installationsmöglichkeiten für Windows Server 2016 geben wird.

• Server mit Desktop – bekannt unter "Server with GUI"
• Server Core – ohne GUI
• Nano Server

Server mit Desktop wird den Anwendungsbereich der Remote Desktop Services abdecken und wird für Szenarien relevant, in denen ein User Interface benötigt wird. Auch die Microsoft Management Konsole (MMC), Server Manager und die bekannten Tools werden zur Verfügung stehen.

Der Begriff Server Core kam erstmals mit Windows Server 2008 auf. Gemeint ist damit eine reduzierte Installation, die es nur erlaubt, bestimmte Windows-Server-Rollen zu installieren. Damit reduziert sich ebenfalls die Anzahl an potentiellen Sicherheitslücken.

Nano Server ist eine weitere Deployment-Option, die sich besonders auf Anwendungen fokussiert, die in der Cloud zum Einsatz kommen. Der Unterschied zum Core-Server ist dabei, dass der Nano Server nur per WMI oder Powershell konfiguriert werden kann. Remote-Desktop-Support fällt ebenfalls komplett weg.

Servicing-Modelle für Windows Server 2016

Neu sind die Servicing-Modelle für Windows Server – allerdings nur beim Nano-Server.

Der Server mit Desktop Experience und der Server Core werden im klassischen Modell – Microsoft spricht hier vom "5+5 model" bleiben und wählt die Begrifflichkeit LTSB. Nano Server wird periodisch neue Releases erhalten. Geplant sind zwei bis drei Releases pro Jahr.

Auch System Center 2016 wird in diesem Zeitraum Release to Manufacturing. Die Produktfamilie System Center ist Microsofts Lösung für hybride Rechenzentren. In der Version 2016 wird sie bestehen aus:

• Virtual Machine Manager (VM Management)
• Operations Manager (Monitoring)
• Configuration Manager (Client- bzw. Device Management)
• Orchestrator oder Service Management Automation (SMA)
• Data Protection (Backup and Recovery)
• Service Manager (Workflows, Helpdesk, etc.)

Eine nicht weniger spannende Nachricht war auch der Releasezeitraum von Microsoft Azure Stack für Mitte 2017. Azure Stack ist ein Hybrid Cloud- Plattformprodukt und die Weiterentwicklung von Microsoft Azure Pack. Mit Azure Stack können Unternehmen die Lösungsmöglichkeiten oder Vorteile von Clouddiensten nutzen. Da diese Software im eigenen Rechenzentrum läuft behalten Sie dennoch die Kontrolle über ihre Services und Daten. Weiterhin bietet Azure Stack auch Schnittstellen zur Public Cloud, was Szenarien ermöglicht in denen Unternehmen bspw. kurz oder mittelfristig skalieren müssen oder bewusst Clouddienste mit einbinden wollen.

Für viele Arbeiten benötigt man administrative Rechte auf eine Gruppe von Zielrechnern. Um schnell herauszufinden, ob man mit einem bestimmten Account solche Rechte auf entfernte Windows-Rechner hat, eignet sich die folgende Quick-and-dirty-Lösung.

Man ruft hierbei ein Batch-Skript auf, das sich mit der Admin-Freigabe des Zielrechners zu verbinden versucht. Glückt dies, so hat man Adminrechte. Schlägt es fehl, dann fehlen die Rechte.

Wichtig: Das ist eine sehr simple Lösung, die auf besondere Eleganz verzichtet. Für manche Zwecke reicht sie aber aus.

Zur Nutzung meldet man sich mit dem Account an, den man prüfen möchte, und ruft ein CMD-Fenster mit Adminrechten auf. Je nach Situation kann es auch ausreichen, das CMD-Fenster ausdrücklich mit dem zu testenden Account zu starten.

Die folgende Batchdatei speichert man als “Test-AdminAccess.bat” und ruft sie für jeden zu prüfenden Rechner einmal auf.

@ECHO OFF
NET USE B: /DELETE
NET USE B: \\%1\Admin$
IF EXIST B:\ (
	SET SUCCESS=OK
	) ELSE (
	SET SUCCESS=ERROR)
ECHO %1;%SUCCESS%>>adminaccess.txt
NET USE B: /DELETE

Der Aufruf geht folgendermaßen, auch hier kann man sich gut mit Excel behelfen, um die Aufrufe zu generieren:

Test-AdminAccess.bat PC0815
Test-AdminAccess.bat PC4711
Test-AdminAccess.bat PC007

Die Ergebnisse stehen in der Datei adminaccess.txt, die man z.B. mit Excel öffnen und auswerten kann.

Mit Windows 10, insbesondere dem “Anniversary Update” auf die Version “1607”, ändert Microsoft die Anwendungslogik von Gruppenrichtlinien. Künftig unterscheidet die Technik nicht nur Versionen des Betriebssystems (Windows 7, Windows 8, Windows 10), sondern auch die Edition (Pro, Enterprise).

Näheres dazu findet sich in einem Beitrag, den ich für den heise-Newsticker geschrieben habe:

[Unter Windows 10 Pro gelten bald nicht mehr alle Gruppenrichtlinien | heise online]
http://www.heise.de/newsticker/meldung/Unter-Windows-10-Pro-gelten-bald-nicht-mehr-alle-Gruppenrichtlinien-3281404.html

Im Lauf des 2. August 2016 hat Microsoft die Version “1607” von Windows 10 veröffentlicht, auch bekannt als “Anniversary Update”. Es steht für alle (Desktop-) Editionen bereit und ist über die bekannten Kanäle erhältlich. Vorhandene Installationen sollten das Upgrade in den nächsten Tagen und Wochen weitgehend automatisch erhalten. Wie bisher ist für den eigentlichen Upgrade-Prozess eine Downtime für den Client erforderlich, weil er faktisch neu installiert wird.

Neu sind zwei Ausgaben für Bildungseinrichtungen: Windows 10 Education und Windows 10 Pro Education. Die vorhandene Enterprise-Edition, die nur mit aktiver Software Assurance erhältlich ist, wertet Microsoft um weitere exklusive Funktionen auf. (Die weniger positive Darstellung dazu: Microsoft schränkt die Pro-Ausgabe funktional weiter ein.) Viele Anpassungen des Systems, insbesondere für die optische und funktionale Konfiguration, sind künftig an die Enterprise-Edition gebunden. Wer also Wert auf einheitliche Desktop-Konfigurationen im Unternehmen legt, sollte diese (teure) Variante wählen.

Ebenfalls neu ist, dass Microsoft den geplanten Upgrade-Zeitplan deutlich streckt. Hieß es ursprünglich, es sei etwa alle drei Monate mit einem neuen Release zu rechnen, so ist die aktuelle Version 1607 die einzige, die in diesem Jahr erscheint. Für 2017 sind zwei Ausgaben angekündigt. Gemäß den Upgrade-Vorgaben werden “normale” Installationen in den nächsten Wochen automatisch aktualisiert. In Unternehmen, die mit dem “Current Branch for Business” arbeiten, wird die Version 1607 in etwa vier Monaten zum neuen Standard.

Herausragendes neues Feature ist “Windows Information Protection”, früher bezeichnet als “Enterprise Data Protection”. Diese Funktion soll zentral dazu beitragen, dass Unternehmensdaten bei privater Nutzung des Rechners nicht missbraucht werden können. Ursprünglich sollte diese Technik schon im ersten Release von Windows 10 verfügbar sein, doch die Entwicklung hatte sich erheblich verzögert.

Näheres zum Release:

[What’s new for IT pros in the Windows 10 Anniversary Update – Windows for IT Pros]
https://blogs.technet.microsoft.com/windowsitpro/2016/08/02/whats-new-for-it-pros-in-the-windows-10-anniversary-update/