Weisheiten - der Netz-Weise Blog

Virtuelle Maschinen in Windows Azure speichern Ihre Daten genau wie in Hyper-V in VHD-Dateien. Azure unterstützt dabei allerdings nur das Fixed Size VHD-Format, also weder VHDX noch dynamische Vergrößerung.

Fixed Size VHDs werden bereits bei der Erstellung der VHD mit der Gesamtgröße der Datei angelegt. Erstellen Sie also eine Datei mit 100 GB Größe, nimmt diese auch 100 GB Speicherplatz auf dem Datenträger ein. Damit die Daten auf dem Storage in Azure aber nicht durch Leerdaten zugemüllt werden (und Sie leere Festplatten auch nicht bezahlen müssen, denn die VHDs werden u.a. über den verwendeten Speicherplatz bezahlt), verwaltet der Azure-Storage die VHD-Dateien als Sparse-Daten, was nichts anderes heißt als dass nur die wirklich verwendeten Bereiche der VHD-Datei gespeichert werden. Damit das effizient passieren kann, muss die VM in regelmässigen Abständen der Festplatte (also der VHD) mitteilen, welche Daten wirklich gelöscht wurden - normalerweise entfernen Löschvorgänge nur die Einträge in der Verwaltungsdatei des Dateisystems, bei NTFS die MFT oder Master File Table. Der Datenträger bekommt also gar nicht mit, welche Daten nicht mehr verwendet werden. Spätestens seit SSDs wissen wir, dass es eine gute Idee ist, dem Datenträger ebenfalls mitzuteilen, welche Speicherbereiche gelöscht wurden. Das passiert über den Trim-Befehl, der das Dateisystem mit dem Datenträger abgleicht.

Für in Standard-Storage (nicht auf SSD) abgelegte, manuell verwaltete ("Ungemanagte") Datenträger sollten Sie prüfen, ob Trim aktiviert ist - bei allen andern Varianten wird das automatisch verwaltet. Öffnen Sie hierfür in der Azure-VM eine Kommandozeile und verwenden Sie das File-System-Utility (fsutil.exe) zum prüfen:

fsutilbehavior query DisableDeleteNotify

Wenn fsutil 1 zurück gibt, ist Trim deaktiviert. Zum aktivieren verwenden Sie folgenden Befehl:

Im letzten Tipp habe ich gezeigt, wie man Zertifikate mit Powershell Base64-kodiert aus dem Zertifikatsspeicher exportieren kann. Wenn man versucht, mit dem Cmdlet Export-Certificate eine pfx-Datei zu erstellen, - die pfx-Datei ist ein Container, der neben dem Zertifikat auch den privaten Schlüssel enthält und tatsächlich eigentlich das PKCS #12-Formate enthält - stellt man allerdings fest, dass das Cmdlet dazu nicht in der Lage ist. Tatsächlich ist es aber kein Problem - man muß nur das richtige Cmdlet verwenden. Denn zum Export als .pfx-Datei verwendet man Export-PFXCertificate. Die Datei muß allerdings mit einem Kennwort gesichert werden, um den privaten Schlüssel zu  sichern:

$pwd = ConvertTo-SecureString -String "geheim" -AsPlainText -Force

Get-ChildItem -Path Cert:\CurrentUser\My\ | Where-Object { $_.subject -eq "cn=NWCertRoot" } |

    Export-PfxCertificate -FilePath $home\NwcertRoot.pfx -Password $pwd 

Mit Powershell auf den Zertifikatsspeicher zurückzugreifen, ist sehr simpel, denn Powershell stellt für den Zugriff auf Zertifikate einen Powershell-Provider bereit. Durch den Provider ist es möglich, Zertifikate wie Dateien zu behandeln. Der Provider legt hierfür ein "Laufwerk" mit Namen Cert: an. Möchten Sie z.B. die Zertifikate des aktuellen Benutzers sehen, geben Sie ein:

PS C:\Users\Holger> Get-ChildItem -Path Cert:\CurrentUser\My\

PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                               Subject
----------                               -------
A83FA591D2D909D7465768ED4F7DE4019026F74D CN=Holger
7154EBF108BEB11587B1136B06EC5C24E3E6CAEA CN=NWCertRoot
6C0CEA5EC15CA5E6350CB9E7D02D90C9AA1DEBE3 CN=NwClientCert

Zurückgeliefert wird der eindeutige Thumbprint des Zertifikats, sowie dessen Name. Um ein Zertifikat ins Dateisystem zu exportieren, verwenden Sie das Cmdlet Export-Certificate:

Früher war es sehr einfach, Office auf einem Terminal Server zu installieren. Heutzutage ist die Installation auf einem RDP-Server komplizierter geworden. Nicht aufgrund der Installation, sondern aufgrund der Lizenzbedingungen. Denn ein Office 2016 kann nicht mehr einfach auf einem RDP-Server bereitgestellt werden - wenn es sich nicht um eine Volumenlizenz handelt, funktioniert die Installation zwar, aber danach startet das Office leider mit einer Fehlermeldung. 

Eine Alternative bietet sich an, wenn man Office 365 lizenziert hat. Die Installation ist allerdings wiederum nicht mit dem Aufrufen des Setups getan, da Office 365 eine alterantive Installationsmethode benötigt. Office 365 wird durch das Office Deployment Tool bereitgestellt, dass man bei Microsoft herunterladen kann. 

Die eigentlichen Installationschritte sind recht simpel. Office 365 wird in Form eine App-V Pakets installiert, dass von Microsoft bereitgestellt wird. Das Paket wird direkt bei Microsoft heruntergeladen, man benötigt also keine Installations-CD mehr. Das Herunterladen wird durch das Deployment Tool initialisiert. 

Damit nur die notwendigen Komponenten heruntergeladen werden, kann man dem Deployment-Tool über eine Konfigurations-Datei (Configuration.XML) sagen, welche Teile des Office-Paktes bereitgestellt werden sollen. Die Standarddatei sieht so aus:

<Configuration>
  <Add OfficeClientEdition="32" Channel="Current">
  <Product ID="O365ProPlusRetail">
     <Language ID="en-us" />
  </Product>
  <Product ID="VisioProRetail">
    <Language ID="en-us" />
  </Product>
</Add>
<!-- <Updates Enabled="TRUE" Channel="Current" /> -->
<!-- <Display Level="None" AcceptEULA="TRUE" /> -->
<!-- <Property Name="AUTOACTIVATE" Value="1" /> -->
</Configuration>

Manchmal steht man vor der Aufgabe, das einzelne mails aus einem Benutzerpostfach gelöscht werden sollen, z.B. weil Sie Schadcode enthalten, oder auch, weil das Postfach geleert werden soll. Mit Hilfe der Exchange-eigenen Cmdlet Search-Mailbox geht das sehr einfach.

Starten Sie die Exchange Management-Shell. Eine Anleitung der Installation der Shell finden Sie im Artikel "Exchange Cmdlet in Powershell nutzen". Achten Sie darauf, dass Sie das Cmdlet "Search-Mailbox" nicht sehen, solange Sie nicht Mitglieder der Rolle "Mailbox Import Export" sind - das gilt sogar dann, wenn Sie als Organisationsadministrator angemeldet sind. Alternativ können Sie das Problem auch umgehen, indem Sie die Exchange-Snapins direkt importieren. 

Anschliessend rufen Sie das Cmdlet Search-Mailbox auf. Der Parameter Identity gibt dabei an, welche Mailbox(en) Sie suchen. Alternativ können Sie die Mailboxen auch per Pipeline an Search-Mailbox übergeben. Mit Hilfe des Parameters -Searchquery geben Sie an, welche Nachrichten gesucht werden. Das Cmdlet verwendet für die Definition der Suchabfragen die KQL (Keyword Query Language). Ein einfaches Beispiel für eine Suche nach dem Begriff "Verrat" in allen mails aller mailboxen sieht so aus: 

Get-Mailbox | Search-Mailbox -SearchQuery 'Verrat' -TargetMailbox 'Administrator' -TargetFolder 'NSA' 

Wenn Sie Exchange 2013 oder 2016 per Powershell remote administrieren wollen, ohne sich auf den Exchange-Server per Powershell Remoting zu verbinden, oder wenn Sie Scripte von einer Management-Maschine aus starten wollen, brauchen Sie die Exchange-Snapins. Diese müssen Sie von den Exchange-Quellen nachinstallieren. Um die Installation starten zu können, müssen Sie allerdings eine Reihe von Software-Komponenten installiert haben. Am einfachsten geht dies über den Powershell-Befehl "Enable-WindowsoptionalFeature" auf dem Client bzw. Install-WindowsFeature auf dem Server:

Enable-WindowsOptionalFeature -Name IIS-WebServerRolead,IIS-WebServerManagementTools,IIS-IIS6ManagementCompatibility,IIS-Metabase,IIS-ManagementConsole,IIS-LegacySnapIn

Danach können Sie (für Exchange 2013) einfach über das Setup die automatisiert Installation der Exchange Management-Shell aufrufen:

Setup.exe /Role:ManagementTools /IAcceptExchangeServerLicenseTerms

Für die Installation können Sie einfach das aktuellste Exchange CU (Cumulative Update) nutzen, da das CU die komplette Exchange-Installation beinhaltet. 

Mit Office 365 steht Ihnen seit einiger Zeit die Möglichkeit zur Verfügung, eine Multifaktor-Authentifzierung zu aktivieren, um die Sicherheit beim Login zu erhöhen. Was MFA ist, warum man es aktivieren sollte und wie das geht, zeigt Ihnen dieser Artikel.

Was ist MFA?

MFA steht für Multifaktor-Authentifizierung und bezeichnet ein Verfahren, bei dem ein Benutzer sich über mehrere Kritieren identifizieren muß. Klassischerweise identifiziert man sich über eine Kennwort, aber die reine Kenntwortauthentifizierung ist aus verschiedenen Gründen nicht wirklich sicher, denn so ein Kennwort kann z.B. abhanden kommen (jemand hat den Sticker unter der Tastatur gefunden) oder gehackt werden. Das ist vor allem schon deshalb sehr unangenehm, weil Kennwörter aufgrund der Komplexität oft schwer zu merken sind und von vielen Benutzern einfach nur mit einem Zähler versehen werden. Mit Wörterbuchattacken ist es außerdem oft sehr einfach, ein Kennwort innerhalb kurzer Zeit zu hacken. 

Die Idee hinter der Multifaktorauthentifizierung ist nicht neu. Schon Windows 2000 hat die Authentifizierung über Smartcards erlaubt. Mit MFA werden neben dem Geheimnis, das der Benutzer und der Anmeldeserver kennen (das Passwort), weitere Authentifzierungen gefordert. Bei der Smartcard ist das neben der PIN eben die Smartcard, die in den Leser geschoben werden muß. Bei RSA-Tokens ist das ein alle 30 Sekunden neu generierter Zahlencode. Der Vorteil liegt darin, dass die Kenntnis des Kennworts nicht ausreicht, um an die Benutzerdaten zu gelangen. Es wird mind. ein zweiter Faktor benötigt - in den meisten Fällen ein Stück "Hardware" - um die Authentifzierung abzuschließen. So ein Stück Hardware kann dabei prinzipiell alles sein, auch ein spezifisches Geräte. Das macht sich Microsoft z.B. mit Windows Passport zunutze, indem die Authentifizerung mit einer einfachen PIN durchgeführt wird, aber immer an ein spezifisches Geräte gebunden ist. 

Meistens ist so ein Stück Hardware aber teuer. Ein RSA-Token kostet pro Token viel Geld, für Smartcards benötigt man neben der Smartcard auch noch ein Lesegerät. Heutzutage trägt aber fast jeder ein Token freiwillig überall mit sich herum - das Smartphone. Daher ist MFA heutzutage recht erschwinglich geworden. Einmalcodes, wie Sie von RSA-Tokens generiert werden, können nämlich z.B. auch durch die Microsoft Authenticator App generiert werden, die auf allen mobilen Plattformen (Windows Phone, Android, IOS) zur Verfügung steht. Alternativ können Tokens auch per SMS oder Anruf übertragen werden. 

MFA in Office 365 aktivieren

Office 365 unterstützt über die Azure AD Integration seit einiger Zeit auch die MFA per Smartphone. Die Einrichtung hierfür ist recht simpel. Gehen Sie ins Office 365 Admin-Center, wählen Sie unter Users > Active Users einen Benutzer aus, und wählen Sie im Benutzermenü "Manage Multi-factor Authentication". 

Viele Anwendungen benötigen zur Verbindung mit einem Datenbankserver eine ODBC-Datenquelle. Eine Datenquelle (oder auch DSN - Data Source Name) ist letztendlich nichts weiter als eine auf dem System hinterlegt Konfiguration, die der Anwendung sagt, wie Sie einen Datenbankserver über die ODBC-Schnittstelle (Open Database Connector) ansprechen kann. 

Wenn Sie auf Ihrem Rechner eine ODBC-Datenquelle konfigurieren wollen, können Sie hierfür einen Assitenten verwenden. Geben Sie dafür im Startmenü / Startbildschirm einfach ODBC ein. Windows sollte Ihnen dann zwei möglichen Konfigurationsprogramme anbieten: ODBC-Datenquellen (32-Bit) und ODBC-Datenquellen (64-Bit).

Welche Datenquelle Sie benötigen, hängt dabei einzig von Ihrer Anwendung ab. Verwenden Sie eine 32-Bit Applikation (wie nach wie vor fast alle Office-Programme), benötigen Sie eine 32-Bit Datenquelle, für eine 64-Bit Applikation benötigen Sie eine 64-Bit Datenquelle. 

Die Unterschiede zwischen 32-und 64 Bit liegen im Detail. Zum einen werden unterschiedliche Treiber verwendet. Zum anderen werden, wenn Sie User- oder System-DSNs (Data Source Name) anlegen, 32-Bit-Schlüssel in der Registry nicht unter Software\ODBC angelegt, sondern unter Software\WOW6432Node\ODBC\. Daher ist wichtig, welchen Assistenten Sie zum Anlegen der Datenquelle verwenden. Beide heißen ODBCAD32.exe, liegen allerdings in unterschiedlichen Ordnern. Um beim Anlegen einer 32-Bit-Datenquelle sicher zu stellen, dass Sie wirklich den richtigen Assitenten verwenden, starten Sie den 32-Bit Assistenten am Besten direkt aus %windir%\SysWow64\odbcad32.exe. 

Diese Registry-Werte können Sie über Gruppenrichtlinien (in den Gruppenrichtlinien-Einstellungen oder Prefrences) direkt wieder importieren und dann verteilen, ohne den Assistenten noch einmal bemühen zu müssen. Navigieren Sie dazu einfach in der Computer- oder Benutzerkonfiguration auf Preferences\Windows Settings\Registry und starten Sie über das Kontextmenü des Schlüssels unter dem Eintrag New den Registry-Wizard. Das setzt allerdings voraus, dass Sie die ODBC-Datenquelle auf dem Computer, auf dem Sie die Gruppenrichtlinie konfigurieren, vorher angelegt haben. 

Wenn Sie ein Gruppenrichtlinienbackup erstellen, wird für jede GPO ein eigener Sicherungsordner angelegt. Der Sicherungsordner trägt allerdings nicht den Namen der GPO, sondern es wird für jede Sicherung eine eigene GUID erstellt.

Wenn Sie die Sicherung in der Domäne wiederherstellen möchten, in der Sie die Sicherung angelegt haben, ist das nicht problematisch, da die GPMC Ihnen über "Manage Backups" auf den Container "Group Policy Objects" die Details Ihrer Backups anzeigt. Wenn Sie die Backups allerdings auf eine andere Domäne übertragen wollen, fehlen Ihnen diese Informationen. Vor allem bei umfangreichen Backups hilft dann nur eine gute Dokumenation oder die folgenden beiden Funktionen, die einen Backup-Ordner einlesen und die relevanten Informationen auslesen können.

ConvertFrom-GPVersion konvertiert die 32-Bit Versionsnummern der Computer- bzw. Benutzerkonfiguration in einen dezimalen Versionswert. Sie wird von Get-GPOBackupInfoFromXML verwendet, um die korrekte Version der User-bzw. Computerkonfiguration zu berechnen. Beide Funktionen sind auch Bestandteil des aktuellen GPHelper-Powershellmoduls. 

function ConvertFrom-GPVersion

{

Leider bietet das Powershell AD-Modul keine Möglichkeit, auf das Vorhandensein einer Organizational Unit zu testen. Diese Funktion lässt sich aber einfach nachrüsten. 

Grundsätzlich kann man die Existenz einer OU testen, indem man einfach das Cmdlet Get-OrganizationalUnit verwendet. Prüft man die Abfrage in einer IF-Bedingung, wird der Scriptblock des IF ausgeführt, wenn die OU existiert. Das Ganze hat allerdings einen Haken, denn Get-ADOrganizationalUnit bricht die Skriptverarbeitung mit einem unbehandelten Fehler ab, wenn die OU nicht existiert.

If ( Get-ADOrganizationalUnit -Identity "OU=test,DC=Netz-Weise,DC=DE" ) { $true }
get-adorganizationalUnit : Directory object not found

Dieses Verhalten kann man sich zunutze machen, indem man die Ausführung des Get-ADOrganizationalUnit mit Try-Catch ausführt. Wird ein unbehandelter Fehler ausgeführt, wird die Catch-Block aufgerufen und ausgeführt. In diesem muß man jetzt nur noch einen $False zurück liefern. 

function Test-ADOrganizationalUnit