Weisheiten - der Netz-Weise Blog

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. 

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

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. 

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>

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:

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 

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:

Update: Ein Artikel zur Aktivierung der Suche unter Windows Server 2016 finden Sie hier: https://www.netz-weise-it.training/weisheiten/tipps/item/397-windows-server-2016-startmenue-findet-keine-programm.html

Wenn Sie Windows 10 installiert haben und sich regelmässig darüber ärgern, dass die Suche installierte Desktop-Programme nicht findet, hier 2 Tipps, die helfen. Achten Sie darauf, dass Sie für beide Aktionen Administrator-Rechte benötigen. 

Tipp 1 - Installieren Sie die Cortana-App neu

Anscheinend hat die Cortana App ein Problem, das sich mit einer Neuinstallation beheben lässt. Öffnen Sie hierfür zuerst ein administratives Powershell-Fenster (rechtklick auf das Powershell-Icon und "Als Administrator ausführen" wählen. 

Als nächstes beenden Sie den Windows Explorer. Der von Microsoft vorgesehene Weg führt dazu über einen Rechtsklick bei gedrückt gehaltener Strg+Shift-Taste auf die Taskleiste. Im Kontextmenü erscheint als unterster Punkt "Explorer beenden". 

Mit Windows 10 und der nächsten Version von Windows Server fehlen noch einige kompatible Treiber. So jubeln Sie Windows nicht für die Version vorgesehen Treiber unter Treiber, Treiber, Treiber. Immer wieder stößt man auf Hardware, die vom Betriebssystem nicht unterstützt wird, weil die Hardware zu alt ist oder man auf einem Serversystem (testweise) arbeitet, für das keine Treiber zur Verfügung gestellt werden. Die Krux an der Sache - oft gibt es funktionsfähige Treiber, aber der Hersteller hat den Treiber nur für z.B. Windows Clients zur Verfügung gestellt oder aber man arbeitet mit einer neuen Version des Betriebssystems, für die noch keine neuen Treiber existieren, obwohl die alten funktionieren würden.  Im folgenden Beispiel beschreibe ich, wie Sie einen Intel-Treiber für den in der CPU integrierten Intel GM 4000 Grafikadapter unter Windows Server Next (Windows Server 2016) zum Laufen bekommen.  Besorgen Sie sich zuerst einen Treiber für Windows 8.1 64 Bit. Den können Sie bei Intel bekommen. Eine gute Alternative Treiberquelle ist Microsoft Update, denn Microsoft stellt oft noch Treiber für Produkte zur Verfügung, die vom Hersteller gar nicht mehr unterstützt werden. Die Microsoft-Treiber finden Sie unter http://catalog.update.microsoft.com.  Laden Sie den Treiber als cab-File oder zip-File herunter, und entpacken Sie ihn. Wenn er, wie bei MS Update, als .cab-File geliefert wird, doppelklicken Sie einfach die cab-Datei im Explorere, markieren Sie dann alle Dateien im Ordner und rechtklicken Sie eine Datei. Es wird dann der Menüeintrag "Extract" angegeben. Extrahieren Sie die Dateien z.B. in C:\treiber\intelGM.  Nachdem die Dateien extrahiert sind, suchen Sie im IntelGM-Ordner die Datei mit der Endung .inf und editieren die Datei im Notepad. In der inf-Datei ist für jedes unterstützte Betriebssystem ein Eintrag vorhanden, der ungefähr so aussieht:

;=====================================================================
;    Windows 8 Install
;=====================================================================
[IntelGfx.NTamd64.6.2] [...]

Das ; ist einfach nur ein Kommentar. Wichtig ist der Teil [IntelGfx.NTamd64.6.2], da die Zahl 6.2 das Betriebssystem angibt. Windows 10 und Windows Server Next haben die internen Betriebssystemnummer 6.4, und für die müssen wir einen Eintrag erstellen, damit Windows den Treiber akzeptiert. Kopieren Sie also den Eintrag mit allen folgenden Werten (die mit % beginnen bzw. bis zum nächsten Kommentar) und fügen Sie ihn unter dem letzten Abschnitt ein. Ändern Sie jetzt den Betriebssystemstring auf 6.4 und, wenn Sie möchten, den Kommentar:

;=====================================================================
;    Windows 10 Install
;=====================================================================
[IntelGfx.NTamd64.6.4]

Da Windows nur signierte Treiber installiert, und wir mit dem Ändern der .inf-Datei die Signatur ungültig gemacht haben, müssen wir Windows jetzt so einstellen, dass es auch unsignierte Treiber akzeptiert. Dazu ändern wir die Starteinstellungen, indem wir eine administrative Kommandozeile öffnen und mit bcdedit die Bootoptionen ändern:

bcdedit -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit -set TESTSIGNING ON

Anschließend starten wir den Computer neu, öffnen den Gerätemanager und wählen das Gerät aus, dass aktualisiert werden soll. Aus dem Kontextmenü des Geräts wählen Sie jetzt "update Driver Software..." aus und nehmen den lokalen Computer als Treiberquelle. Im Folgefenster geben Sie an, dass Sie den Treiber selber auswählen möchten.  Im nächsten Fenster wählen Sie "Have Disk..." aus und geben den Pfad an, in dem sich Ihr bearbeiteter Treiber befindet.  

Powershell stellt mit den Validate-Schlüsselwörtern eine großartige Möglichkeit zur Verfügung, Benutzereingaben in Skripten zu prüfen, und den Code dabei übersichtlich zu halten. Hierfür stehen diverse [Validate]-Attribute zur Verfügung. Folgendes Beispiel prüft z.B. ob ein Parameter sich innerhalb eines bestimmten Wertebereichs befindet:

param(
   [ValidateRange(1,6)]
   [int]$Wuerfelergebnis
)

Rufen Sie den Parameter jetzt z.B. mit 7 auf, erhalten Sie folgende Meldung und das Skript bricht ab:

test : Das Argument für den Parameter "Wuerfelergebnis" kann nicht überprüft werden. Das 7-Argument ist größer als der maximal zulässige Bereich von 6. Geben Sie ein Argument an, das kleiner oder gleich 6
ist, und führen Sie dann den Befehl erneut aus.

Es gibt eine ganze Reihe von Validierungs-Attributen. Eine vollständige Auflistung finden Sie, wenn Sie in der Powershell