Weisheiten - der Netz-Weise Blog

"Windows 8 und Server 2012 bringen das Feature ""Primäre Computer"" mit, die Möglichkeit, ein Benutzerprofil nur auf bestimmten Computern zu nutzen. Bis Windows 8 bedeutete das Anlegen eines servergespeicherten Windows Benutzerprofils, dass ein Benutzerprofil immer auf jeden Computer heruntergeladen wurde, auf dem ein Benutzer sich angemeldet hat. Das kann nicht nur sicherheitstechnisch unglücklich sein - kritische Daten werden überall im Netz verteilt - sondern verlängert auch die Anmeldezeiten auf Sytemen, auf denen man sich nur selten anmeldet. Mit dem Feature primärer Computer kann man dem Benutzer nun einen oder mehrere Computer vorgegen, die das servergespeicherte Benutzerprofil ziehen. Alle anderen Computer nutzen ein lokale Profil. Voraussetzung dafür ist Windows 8 und das AD-Schema von Windows Server 2012, da die Funktion über ein neues Benutzerattribut implementiert wird - msDS-Primary Computer. Richten Sie primäre Computer einfach ein, indem Sie in den DN (Distinguished Name) des Computers kopieren und in das Attribut msDS-Primary Computer des Benutzerobjekts einfügen. Das können Sie über AD Benutzer und Computer machen (indem Sie die erweiterte Ansicht unter "Ansicht" aktivieren und dann im Benutzer den Attributs-Editor verwenden), oder über Powershell:

$computer=Get-ADComputer Computername
Set-ADUser Benutzername –Add @{‘msDS-PrimaryComputer’=”$computer”}

Im nächsten Schritt aktivieren Sie Ordnerumleitungen und / oder servergespeicherte Profile in einer Gruppenrichtlinie, indem Sie im Benutzer oder Computer und Administrative Templates\System\Folder Redirection gehen und ""Redirect Folders on Pirmary Computers only"" wählen. Für Profile heißt die Option ""Download roaming profiles on primary computers only"". "

"Benutzerprofile verwalten - augenblicklich und Betriebssystemversionst-unabhängig - ist das möglich? Ja, mit UE-V!

UE-V (eine kurzform von Microsoft User Experience Virtualization) ist eine Funktion, um Windows Benutzerprofile zu verwalten. Vor kurzem haben wir darüber geschrieben, wie man servergespeicherte Benutzerprofile verwalten kann, wenn man 2 verschiedene Windows-Versionen unterstützen muß. Normalerweise muß man dafür 2 verschiedene Benutzerprofile hinterlegen und die entsprechenden Benutzerordner wie Desktop, Eigene Dateien usw. aus dem Benutzerprofil ""herausziehen"" und auf einer Netzwerkfreigabe speichern. Mit Windows UE-V wird das Benutzerprofil (die Benutzereinstellungen, nicht die Dateien, die ziehen wir weiterhin aus dem Profil heraus) über einen eigenen Dienst verwaltet. Der UE-V Dienst überwacht die Registry und den App-Folder im Benutzerprofil und synchronisiert Änderungen an Anwendungseinstellungen auf ein Netzwerklaufwerk (Share). Diese Änderungen werden nach dem Beenden der Anwendung direkt gespeichert, so dass ein Abmelden zum Synchronisieren der Benutzereinstellungen nicht mehr notwendig ist. Auch Modern Apps (Windows 8 Apps) werden mit UE-V 2.0 unterstützt. Out of the Box bringt UE-V die Unterstützung diverser Anwendungen mit. Für Anwendungen, die nicht von UE-V unterstützt werden, können eigene XML-Konfigurationsdateien mit Hilfe eines mitgelieferten Tools erstellt werden. Das tolle an UE-V ist, dass nicht alle Einstellungen zwischen den Clients eines Rechners synchronisiert werden. Dadurch kann man die Benutzerprofile auch zwischen unterschiedliche Betriebssytemen ohne Verrenkungen verwalten. So, wo ist jetzt der Nachteil des UE-V? Es ist nur als Bestandteil des Desktop Optimization Kits zu bekommen (M-DOP). Warum nur, Microsoft, warum? Verdient ihr mit dem MDOP tatsächlich so viel Geld, dass es sich lohnt, diese Programme nicht zum Bestandteil des Betriebssystems zu machen?"

Ihre auf den Server umgeleiteten Benutzerprofile heissen alle "My Documents" oder "eigene Datien"? Die Desktop.ini ist Schuld! Ein Problem beim Kunden: die meisten der auf den Server umgeleiteten Verzeichnisse werden im Explorer als ""My Documents"" oder ""Eigene Dateien"" angezeigt. Sehr merkwürdig, denn eigentlich kann ein ordnername ja nicht mehrfach im gleichen Verzeichnis auftauchen. Das Problem ist die desktop.ini, die den Explorer anweist, Ordner mit einem bestimmten Symbol zu versehen oder eben umzubennen. Die Desktop.ini liegt im Benutzerordner, und löschen führt dazu, dass wieder der Originalname angezeigt wird. Leider ist das Löschen nicht von Dauer. Um das wiederanlegen der desktop.ini zu verhindern, gibt es verschiedene Möglichkeiten. Zum einen kann man den Schreibzugriff auf die Datei verhindern. Am besten hat mir allerdings der Tipp gefallen, durch einen Eingriff in die Registry (per gpo verteilt) das erstellen der Desktop.ini vollständig zu verhindern - mit der Nebenwirkung, dass der Explorer nun natürlich gar keine desktop.ini Dateien mehr erstellt.

Schlüssel: HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
Name: "UseDesktopIniCache"
Typ:dword
Value: 00000000

Auch das Benutzerprofil von Windows 10 ist wieder nicht mit den Vorgängerversionen kompatibel. Aber Microsoft hat vorgesorgt. Mit Windows 7 hat Microsoft zum ersten mal eine neue Verion des Benutzerprofils eingeführt, um zu verhindern, dass Benutzer mit servergespeicherten Profilen nicht beim Wechsel zwischen Betriebssystemversionen (z.B. auf RDP-Servern) ihr Profil zerschiessen. Dafür legt Windows 7 einen eigenen Profilordner mit der Endung .V2 an. Windows 8 und Windows 8.1 verwenden standardmässig das gleiche Verzeichnis wie Windows 7, nämlich .V2. Man kann allerdings aktivieren, dass auch Windows 8 (.V3) und Windows 8.1 (.V4) sich in eigenen Unterordern schreiben. Installieren Sie hierfür je nach Betriebssytem eines der beiden Hotfixes:

Für Windows 8 das in KB2887239 beschriebene.
Für Windows 8.1 das in KB2887595 beschriebene Hotfix Rollup. 

Danach setzen Sie den folgenden Schlüssel in der Registry:

Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\ProfSvc\Parameters
Name: UseProfilePathExtensionVersion
Wert: 1

Alternativ können Sie dieses Feature auch über Gruppenrichtlinien Einstellungen (Group Policy Preferences) setzen. 

Sie versuchen, ein Update für den CRM-Outlook-Client zu installieren, aber die Installation schlägt mit einer Fehlermeldung wie dieser

“The type initializer for 'Microsoft.Crm.LocatorService' threw an exception.
Cannot load Counter Name data because an invalid index '' was read from the registry.”

fehl? Dann könnte die Ursache fehlerhafte Performance-Counter sein. Klingt merkwürdig? Dachte ich mir auch, aber die Reparatur der Performance-Counter hat trotzdem geholfen. ;-) Geben Sie an der Kommandozeile mit administrativen Rechten einfach

lodctr /r

ein. Überprüfen Sie, ob der CRM-Provider aktiv ist, indem Sie

lodctr /q | find "CRM Client" 

eingeben. Sind die Performance-Counter enabled, können Sie die Installation starten. Ansonsten Registrieren Sie den Client mit

lodctr /e:CRM Client

Danach sollte die Installation des CU (hoffentlich) problemlos funktionieren.

Windows Server bringt eine Reihe von Migrationstools mit, die die Migration von Benutzern, Druckern und Dateien recht einfach machen Sie müssen lokale Benutzer, Gruppen, Drucker oder Dateien zwischen zwei Windows-Server migrieren? Kein Problem mit den Windows Server Migrationstools.

Szenario 1: Benutzer und Gruppen migrieren

Um Benutzer und Gruppen zu migrieren, verwenden Sie die Windows Migration Tools. Auf Windows Server 2008 R2 und 2012 (R2) installieren Sie diese über den Server-Manager oder über Powershell auf dem Quell- und auf dem Zielserver:

Install-WindowsFeature -Name Migration

Danach laden Sie in Powershell das Migrations Snap-In:

Add-PSSnapin Microsoft.Windows.ServerManager.Migration

Exportieren Sie nun zuerst auf dem Quellserver die Benutzer und Gruppen mit Hilfe des Cmdlets Export-SmigServerSettings. Über den Parameter User können Sie angeben, welche Benutzer exportiert werden sollen. Es stehen Ihnen die Optionen "All","Enabled" und "Disabled" zur Verfügung. Wenn Sie auch die lokalen Gruppen exportieren wollen, verwenden Sie den Parameter Group. Achten Sie aber darauf, dass Sie die Gruppen in einem Befehl mit den Usern exportieren, da Sie sonst ein weiteres Export-Verzeichnis benötigen. Das Export-Verzeichnis sollte sinnigerweise von beiden Servern aus erreichbar sein. Da der Export mit Kennwort erfolgt, müssen Sie die Daten mit einem Kennwort verschlüsseln.

Powershell-Module machen das Nachrüsten von Cmdlets einfach, aber was tun, wenn zwei Cmdlets mit unterschiedlicher Funktion den gleichen Namen haben? Beim Erstellen von Cmdlets hat Microsoft eine Reihe von Vorgaben definiert, um das Cmdlet zu bennen. So sollen alle Cmdlets mit einem Verb aus einer vordefinierte Liste (Get-Verb listet die erlaubten Verben auf) erstellt werden. Außerdem soll das Cmdlet aus dem Namen erkennen lassen, was es tut. Das kann aber zu einem Problem führen: Wenn man Cmdlets unterschiedlicher Quellen verwendet, können prinzipiell Cmdlets mit gleichem Namen aber unterschiedlicher Funktion auftreten. Im .Net Framework löst man dieses Problem über Namensräume, aber die gibt es bei Powershell nicht. Die zwei elegantesten Lösungen sind, entweder beim Aufrufen des Cmdlets den Modulnamen vor dem Cmdlet zu setzen:

Hyper-V\get-vm

oder beim Import des Moduls ein Prefix für die Cmdlets zu definieren. Hierbei muß der Import aber vor dem ersten Anwenden eines Cmdlets aus dem Modul erfolgen, weil die Cmdlets sonst doppelt importiert werden:

Import-Module -Name Hyper-V -Prefix HV

SQL-Server kann direkt aus dem SQL-Server heraus mails versenden und nutzt dafür ein System, dass sich SQL Server database mail (SQL Server Datenbankmail) nennt. Database mail kann allerdings nicht direkt versenden, sondern benötigt ein mail relay, also einen Mail-Server, der die Daten weiterleitet. Wenn Sie hierfür Office 365 einsetzen möchten, gehen Sie folgendermaßen vor:

Richten Sie zuerst in Office 365 einen neuen Benutzer ein. Der Benutzer benötigt eine Lizenz für Exchange - wählen Sie erste eine Komplettlizenz für den Benutzer aus und entfernen Sie dann die Lizenzen für die anderen Dienste.  Ganz wichtig - melden Sie sich jetzt einmal mit dem Benutzer an! Der Benutzer muss sein Kennwort ändern. Wenn Sie das nicht tun, wird database-mail am Server keine Anmeldung durchführen können - stattdessen erhalten Sie eine Fehlermeldung:

"The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.1 Client was not authenticated".  

Nach der Änderung des Kennworts wechseln Sie im Menü oben rechts auf "outlook" und stellen im Assistenten die Zeitzone und das Land ein. Im Outlook-Fenster können Sie jetzt auf das Zahnrad oben rechts gehen und Optionen auswählen. Hier finden Sie jetzt unter "Einstellungen über POP oder IMAP" den Mailserver, den Sie als Empfänger angeben müssen.  Nun öffnen Sie die Database-Mail-Einstellungen und konfigurieren den Server:

mailserver: smtp.office365.com (oder was immer bei Ihnen eingestellt war)
SSL-Verschlüsselung aktiv
Basis-Authentifizierung (mit den Benutzerdaten)

Dank Docker gibt es in der aktuellen Preview von Windows 10 und in der Rosetta-Jubiläums-Ausgabe, die Ende Juli erscheint, endlich die Möglichkeit, virtuelle Maschinen in einem isolierten, privaten Netzwerk per NAT mit dem physikalischen Netzwerk zu verbinden, ohne eine Router-VM installieren zu müssen. Der NAT-Switch wurde notwendig, um per Docker bereitgestellte Anwendungen mit den Netzwerk zu verbinden. Und so richtet man einen NAT-Switch ein: 

Legen Sie zuerste mit Hyper-V einen neuen internen VM-Switch an. In früheren Versionen von Windows 10 gab es einen speziellen NAT-Switch, aber der ist zugunsten des internen Switches wieder gewichen:

$NatSwitch = New-VMSwitch -SwitchName Nat -SwitchType Internal

Als nächstes benötigen wir eine Gateway-Adresse für das interne Netzwerk, die wir an den Switch binden. Ein interner Switch legt automatisch auch eine interne virtuelle Netzwerkkarte an. An diese wird die Gateway-IP gebunden. Das folgende Script fragt zunächst den zum Switch gehörenden Netwerkadapter ab. Das passiert in zwei Schritten: Erst wird die virtuelle Repräsentation mit Get-VMNetworkadapter abgefragt, und dann wird die dazugehörige physikalische Netzwerkkarte abgefragt. Es handelt sich dabei um dasselbe Gerät, aber mit zwei unterschiedlichen Cmdlets abgefragt. Diesen umständlichen Weg gehen wir, weil get-Vmnetworkadapter uns den Interface-Index nicht zurück liefert, den wir benötigen, um das NAT-Netzwerk einzurichten: 

$natNetworkAdapter = Get-VMNetworkAdapter -ManagementOS -SwitchName $NatSwitch.Name
$networkAdapter = Get-NetAdapter | Where-Object -FilterScript {
     $_.deviceid -eq $natNetworkAdapter.DeviceId
}

Immer wieder liest man den Mythos, dass man eine Festplatte 37 mal überschreiben muß, bevor die Daten vollständig gelöscht sind. In der aktuellen c´t 13/2016 gibt es dazu einen sehr guten Artikel, der die Hintergründe dazu beschreibt. Das Fazit der Artikelserie lautet: Bei alten MFM-Festplatten, bei denen die Datensektoren der Festplatten noch so groß waren wie Pfannkuchen, war eine Datenwiederherstellung mit den enstprechenden Werkzeugen in der Tat noch möglich. Bei aktuellen magnetischen Datenträgern haben sich die Aufzeichnungsverfahren aber maßgeblich verändert, und auch Datenrettungsunternehmen sind mit Ihren Werkzeugen nicht in der Lage, einmal überschriebene Daten wiederherzustellen. Ach das BSI und das amerikanische Pendant NIST geben als Richtlinie inzwischen heraus, dass eine einfache Überschreibung reicht, um Daten rückstandlos zu entfernen.

Kommen wir nun dazu, wie die Datenlöschung am einfachsten auszuführen ist. Windows bietet dazu 2 Bordmittel an.

Zum Löschen von einzelnen Dateien oder Partitionen auf der Festplatte bietet sich das Tool cipher.exe an. Es ist das Tool zur Kommandozeilensteuerung von EFS (Encrypted File System) und bietet den Schalter /w, mit dem man einzelne Dateien, Ordner oder aber auch ganze Partitionen löschen kann. Um den Ordner c:\Temp\geheim zu löschen und zu überschreiben, geben Sie hierfür ein:

Cipher.exe /w c:\Temp\geheim

Die Löschung kann eine Weile dauern, da die Daten in 3 Durchgängen mit 0, dann mit 1 und anschliessend wieder mit 0 überschrieben werden. Um die ganze Partition zu löschen, geben Sie nur Laufwerksbuchstabe: ein: