Quantcast
Channel: Software – Andy's Blog
Viewing all 1839 articles
Browse latest View live

Voicemeeter Banana als Alternative zu ASIO4ALL mit zwei Soundkarten und VirtualDJ verwenden

$
0
0

Als Alternative zu ASIO4ALL kann man das Ungleich mächtigere Voicemeeter verwenden. Anbei mit einer Onboard- sowie USB-Soundkarte in Verbindung mit VirtualDJ ein Konfigurationsbeispiel.

Voicemeeter Banana konfigurieren

Zunächst Voicemeeter Banana starten. Die beiden zu verwendeten Soundkarte bei „A1“ und „A2“ auswählen.

Darauf achten das beide Soundkarte in Voicemeeter auf die selbe Weise angesprochen werden. Im Idealfall wäre das KS (Kernel Streaming), leider steht dies des Öfteren nicht zur Verfügung, daher dann WDM oder MME verwenden. Andernfalls kommt es zu unterschiedlichen Latenzen was wiederum das Arbeiten erschwert. Dazu im Abschnitt „Troubleshooting“ mehr.

Bei den „Virtual Inputs“ bei „Voicemeeter VIAO“ „A2“ deaktivieren.
Ebenfalls bei den „Virtual Inputs“ bei „Voicemeeter AUX“ „A1“ deaktivieren.

Virtual DJ konfigurieren

Zu beachten ist, das in den Einstellungen von VirtualDJ für „Master“ dann „Voicemeeter Virtual ASIO (ASIO)“ ausgewählt wird, im Mixer von Voicemeeter entspricht das dem Virtual Input „Voicemeeter Viao“. By the way: „Viao 3“ funktioniert an dieser Stelle nicht. Für den Kopfhörer dann „Voicemeeter AUX Virtual ASIO (ASIO)“ auswählen.

Troubleshooting

Verwendet man zwei unterschiedliche Soundkarten kann es trotz identischer Einstellungen Latenzunterschiede geben. Das mag an den Treibern und der Hardware liegen. Eine mögliche Abhilfe kann sein, das „Monitoring Synchro Delay“ in Voicemeeter zu konfigurieren:


Bemerkung

Grundsätzlich gibt es noch mehr Möglichkeiten, so lassen sich die Ausgänge „Master“ und „Kopfhörer“ auch über eine Soundkarte die mehrere Outputs hat ausgeben. Die hier vorgestellte Variante erschien mir die möglichst einfachste zu sein und basiert zudem auf den vorhandenen Gegebenheiten.


Magix: Installierte Seriennummer ermitteln

$
0
0

Bei einem Kunden steht der Austausch diverser älterer PCs an. Bei dieser Gelegenheit sollen natürlich die vorhandenen Anwendungen auf die neuen PCs installiert werden. Nun hat der Kunde mehrere Lizenzen von Magix Foto & Graphic Designer im Einsatz. Unguterweise wurde damals bei der Installation anno 2012/2013 nicht dokumentiert auf welchem PC welche Lizenz verwendet wurde.

Um das nun nachzuholen kann man die Seriennummer nachträglich auslesen. Zu finden ist diese unter

C:\ProgramData\Magix\<Produktname>\installation.ini

im Abschnitt „Serial“.

Bevor man nun die jeweilige Anwendung auf einem neuen PC installiert, muss ggf. die Lizenz auf dem alten Computer deaktiviert werden. Dies gilt für alle Produkte, die eine Seriennummer haben, die mit „P3“ beginnen.

Die Deaktivierung wird im jeweiligen Programm unter

Hilfe - Programm deaktivieren

vorgenommen.

Bei älteren Versionen (Seriennummern die mit „P“ oder „P2“ beginnen) kann es vorkommen, das beim Versuch der Aktivierung eine Meldung erscheint, das die maximale Anzahl an Aktivierungen erreicht oder überschritten wurde. In diesem Fall muss man den Vetrieb kontaktieren:

Tel: +49 (0)5741 3455-31
Montag – Freitag: 9:00 Uhr – 17:00 Uhr

Quellen:

Magix Support – Photo & Graphic Designer

Magix – Forum – Seriennummer?

Windows: Active Directory-Migration von Windows Server 2012 Essentials zu Windows Server 2019 Standard

$
0
0

Bei einem Neukunden haben wir einen Windows Server 2012 Essentials in nicht gerade all zu gutem Zustand vorgefunden. Bevor nun zum einen die Hardware komplett die Grätsche macht, den Geist aufgibt oder wie man es sonst noch nennen mag und uns weitere Macken der Essentials-Umgebung das Administrator-Leben schwer machen, sollte der Server ausgetauscht werden.

Der Ablauf ist eigentlich wie bei jeder Active Directory-/Domänencontroller-Migration:

  • Den neuen Server, inkl. aller aktueller Updates, installieren.
  • Über den Server-Manager oder die Powershell die „Active Directory-Domänendienste“ hinzufügen.
  • Den neuen Server in die Domäne aufnehmen.
  • Zum Domänencontroller hochstufen.
  • Die FSMO-Rollen verschieben. Dazu in der Powershell folgenden Befehl ausführen:
    Move-ADDirectoryServerOperationMasterRole -Identity <NeuerDC> -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

    Die Sicherheitsabfrage entsprechend bestätigen.

  • Nach erfolgtem Verschieben der FSMO-Rollen den Status prüfen. In einer Eingabeaufforderung folgenden Befehl ausführen:
    netdom query fsmo

    Ferner in den Ereignisprotokollen nachsehen, ob Warnungen oder Fehler aufgetreten sind!

  • Bevor man den alten Server herunterstufen und aus der Domäne entfernen kann müssen zunächst die „Active Directory-Zertifikatsdienste“ samt aller Komponenten entfernt werden. Von der Reihenfolge her muss erst die „Zertifikatsstellen-Webregistrierung“ und dann die gesamte Rolle entfernt werden. Ein Neustart ist an dieser Stelle zwingend notwendig.
  • Den alten Server über den Server-Manager oder die Powershell herunterstufen.
    Tipp: Das Herunterstufen kann man in der Powershell testen:
    Test-ADDSDomainControllerUninstallation
  • Den alten Server aus der Domäne entfernen.
  • Optional: Die Domänenfunktionsebenen heraufsetzen.

Vor- und/oder Nacharbeiten

Geht man von einer Essentials-Umgebung weg, sollte man auf den Arbeitsplätzen den „Windows Server Essentials Connector“ deinstallieren.

In den Benutzerobjekten sollte die Pfade zu Basis- und Profil-Ordnern überprüft und ggf. geändert werden.

Ferner sollte man die Gruppenrichtlinien-Objekte mal durchschauen, ob Server-spezifische Einstellungen vorhanden sind. Beispiele dafür sind Netzlaufwerke, Netzwerkdrucker, WSUS, usw.

Gleiches gilt für DHCP und DNS.

Troubleshooting

Während der Migration mussten wir feststellen, das auf dem neuen Domänencontroller zunächst die Freigaben „NETLOGON“ und „SYSVOL“ fehlten. Dies kann passieren, wenn man die Replikation noch nicht abgewartet hat oder, sofern das gesamte Netzwerk schon etwas älter ist, beispielweise ursprünglich mal von Windows 2000 Server oder Windows Server 2003 migriert wurde und anschl. beim Wechsel auf Windows Server 2012 nicht von DFS auf DFRS umgestellt wurde.

Letzteres war hier nicht der Fall, ersteres schon eher. Jedenfalls half es auf dem alten Server den Anweisungen aus dem Ereignis 2213 zu folgenden und etwas zu warten.

Nachdem der alte Server weg war tauchten immer noch Meldungen im Ereignisprotoll der DFRS-Replikation auf. Ein Blick unter

Active Directory-Standorte und -Dienste - Sites - Default-First-Site-Name - Server

offenbarte, das doch noch ein Rest vorhanden war. Dort den alten Server entfernt und etwas Geduld mitgebracht tauchten (bislang) keine neuen Fehlermeldungen mehr auf.

Randbemerkung

Mit diesem Wechsel hat sich dann auch die etwas unschöne Sache mit dem „Nicht-Ändern-können“ der Kennwortrichtlinie erledigt. Beim Essentials geht das entweder über das Dashboard oder die GPO. Leider klappe beides nicht. Das Dashboard meldete zwar immer Erfolg. In der GPO kam das allerdings nicht an.

Ein direktes Ändern mittels GPO, ganz gleich ob mit einer neuen Richtlinien oder beim Editieren einer Bestehenden, endete immer mit folgender Fehlermeldung:
Das Objekt, also die Datei genau genommen, ist im übrigen vorhanden und andere Einstellungen kann man auch erfolgreich vornehmen.

Quellen:

Microsoft TechNet Foren – Trying to migrate a domain from Server 2012 R2 Essentials to a new Server 2019 Standard server

Microsoft Tech Community – How to Migrate Active Directory from Windows Server 2012 R2 to 2019 

Andreas‘ Blog – SYSVOL-Migration von FRS auf DFSR

Dimitris Tonias – Demote a Windows Server 2016 Domain Controller

Microsoft Docs – Schritt 6: Tieferstufen und Entfernen des Quellservers aus dem neuen Windows Server Essentials-Netzwerk

Windows: Standard-Wiedergabegerät per Verknüpfung ändern

$
0
0

Um das Standard-Wiedergabegerät für die Audio-Ausgabe unter Windows zu wechseln sind mehrere Schritte notwendig. Möchte man öfters und vor allem einfacher beispielsweise zwischen Lautsprecher und Headset umschalten geht das mit einem kleinen Tool und entsprechenden Verknüpfungen.

Auf diese Weise erspart man sich nicht nur unnötige Klicks sowie ggf. das Umstecken von Geräten. Lösbar ist das Ganze dank NirCmd und zwei Verknüpfungen

  • NirCmd herunterladen und entpacken.
  • Zwei Verknüpfungen anlegen und folgende Parameter je Verknüpfung hinzufügen:
    setdefaultsounddevice "Headset"

    bzw.

    setdefaultsounddevice "Lautsprecher"
  • Insgesamt muss die Befehlszeile so aussehen:
    C:\Tools\NirCmd\nircmd.exe nircmd.exe setdefaultsounddevice "Headset"

    Pfade sind natürlich anzupassen.

Troubleshooting

Was tun, wenn zwei oder mehr Geräte den gleichen Namen haben, denn dann klappt das Umschalten nicht? Ganz einfach, die Geräte eindeutig benennen. Ein Beispiel:

Wie man sieht gibt es zweimal „Lautsprecher“, einmal passend für die real vorhandenen Lautsprecher und einmal für ein Headset.

  • Das umzubenennende Gerät auswählen und dessen Eigenschaften öffnen.
  • Auf der Registerkarte „Allgemein“ kann der Name geändert werden.

Quelle:

Maurice IT-Blog – Schnell das Wiedergabegerät in Windows wechseln (Headset / Lautsprecher)

Windows: Computer aus der Domäne entfernen und dabei das Benutzerprofil behalten

$
0
0

Manchmal kommt es or das von einem Domänen-Netzwerk auf eine Arbeitsgruppe gewechselt wird oder das einzelne PCs aus der Domänen genommen werden sollen, da sie nur selten eine Verbindung zur Domäne haben bzw. benötigen.

In solchen Fällen und sofern man keine servergespeicherten Profile verwendet, stehen die Chancen nicht schlecht, das man nach dem Entfernen des Computers aus der Domäne das Benutzerprofil dennoch übernehmen kann.

Die sauberste Methode wäre einen neuen lokalen Benutzer samt Profil anzulegen und die notwendigen Daten aus dem Domänenprofil zu kopieren.

Weniger Arbeit macht es mittels ForensiT User Profile Wizard das vorhandene vormalige Domänenprofil zu einem lokalen „Arbeitsgruppen-Profil“ zu machen.

  • Eine Datensicherung erstellen, für den Fall das etwas schief läuft!
  • Das Tool herunterladen, die *.msi-Datei kann entweder mittels Ausführen oder beispielsweise mit 7-Zip entpackt werden. Eine Installation ist nicht notwendig.
  • Eine lokalen Benutzer, dem das Profil zugewiesen werden kann, anlegen.
  • „User Profile Wizard“ ausführen.
  • Den lokalen Computernamen und den Benutzernamen des zuvor neu angelegten lokalen Benutzers angeben.
  • Den Domänenbenutzer auswählen oder sofern der Domänenbenutzer bzw. dessen Profil nicht angezeigt wird, dann „Unassigned Profiles“ auswählen und das Benutzerprofil auswählen.
  • Auf „Weiter“ klicken und auf den Abschluss der Profil-Migration warten.
  • Sobald der Vorgang beendet ist, kann sich der lokale Benutzer anmelden.

Kaspersky Small Office Security stört die Verwaltung und Erreichbarkeit im Domänen-Netzwerk

$
0
0

Vor nicht allzulanger Zeit haben wir die Betreuung eines Handwerksbetriebs übernommen. Dieser setzt unter anderem Kaspersky Small Office Security auf seinen Windows 7 Professional sowie dem Windows Server 2012 Essentials ein.

Recht schnell wunderten wir uns, das verschiedene Netzwerk- wie auch Administrations-bedingte Dinge nicht funktionierten. So scheiterte beispielsweise schon ein simpler Ping, von Remotedesktop oder den typischen administrativen Möglichkeiten vom Server aus um beispielsweise auf den Arbeitsplätzen mittels administrativer Freigabe etwas abzulegen ganz zu Schweigen.

Quasi sofort war klar, das es an der Firewall liegen musste. Die Windows-eigene Firewall meldete das sie von Kaspersky verwaltet wird. Dort wiederum findet man die Regeln zu RDP und Co. unter dem Punkt „Paketregeln anpassen“. Kurios dabei ist, das Ping  („ICMP Echo Reply“) zugelassen ist, aber dennoch nicht funktioniert.

Soweit sieht es lokal aus, aus der Ferne, d.h. via MyKaspersky, kann man nur die Firewall ein- oder abschalten. Eine umfangreichere zentrale Verwaltung ist offenbar nicht vorgesehen. Jedenfalls bevor weiter Fehler gesucht werden haben wir schlicht die Kaspersky-eigene Firewall deaktiviert.

Lokal:

  • „Kaspersky Small Office Security“ öffnen.
  • Auf „Einstellungen“ (Zahnrad-Symbol links unten) klicken.
  • Auf „Schutz“ klicken.
  • Die Firewall oder andere gewünschte Komponenten deaktivieren.

MyKaspersky:

  • Anmelden.
  • Zu „Geräte“ wechseln.
  • Den PC auswählen und auf „Verwalten“ klicken.
  • Zu „Komponenten“ wechseln.
  • Die Firewall oder andere gewünschte Komponenten deaktivieren.

Tipp: Damit der Anwender nicht durch Meldungen à la „Sicherheit gefährdet“ irritiert wird, die Meldung das die Firewall deaktiviert ist in Kaspersky auf „Ignorieren“ setzen. Scheinbar geht dies nur lokal am PC.

Die Windows-Firewall ist aktiv und gepflegt und nun läuft alles auch so wie es soll.

Epson Perfection 1660 Photo-Scanner unter Windows 10 (nach Upgrade von Windows 7) verwenden

$
0
0

Nach dem Upgrade von Windows 7 zu Windows 10 funktionierte zunächst ein Epson Perfection 1660 Photo-Scanner auf einem Notebook nicht mehr.

Das Gerät hat schon etliche Jahre auf dem Buckel und war bereits unter Windows 7 auf Anhieb nicht gleich zum Laufen zu bringen.

Ein Blick in den Geräte-Manager verriet, das kein Treiber installiert war. Seitens des Herstellers gibt es schon lange keine Unterstützung mehr.

Abhilfe für diesen Fall schuf die manuelle Installation des Treibers im Geräte-Manager, bei der Auswahl unter „Bildverarbeitungsgeräte – EPSON“ stand lediglich ein EPSON Expression 1680 zur Verfügung, dieser konnte ausgewählt und nach der Bestätigung einer Warnung installiert werden.

Nun kann wieder mit EPSON Scan gearbeitet werden.

Unklar ist, woher der 1680er Treiber stammt. Es kann gut sein, das dieser seinerzeit schon bei der Windows 7-Installation verwendet wurde.

Windows: Automatisch OpenVPN-Verbindung inkl. Anmeldung herstellen

$
0
0

Um automatisch eine OpenVPN-Verbindung aufbauen zu können gibt es gleich mehrere Möglichkeiten. So gibt es die automatische Anmeldung wenn der Client durch den Benutzer gestartet wird. Möchte man automatisch für den Computer die Verbindung aufbauen, unabhängig vom (Windows-)Benutzer bzw. dessen Anmeldung, so geht dies ebenfalls und zwar durch den OpenVPN-Dienst.

Dieser Beitrag fußt auf der Community-Ausgabe von OpenVPN. Für das Vorhaben bzw. bei der Installation wird lediglich der Client ansich und das TAP-Interface benötigt. Auf die GUI und die Cert-Tools kann verzichtet werden.

  • Die *.ovpn-Datei die man beispielsweise aus einer pfSense, Securepoint UTM, … exportiert hat muss um folgendes ergänzt werden:
    auth-user-pass pass.txt

    I.d.R. fehlt nur die Angabe einer Text-Datei. Diese muss erstellt werden und wie folgt aufgebaut sein:

    <Benutzername>
    <Kennwort>
  • Die *.ovpn-, sofern vorhanden die Zertifikats-/Schlüsseldateien, sowie die „pass.txt“ unter
    "C:\Program Files\OpenVPN\config"

    platzieren.

  • Den Dienst „OpenVPNService“ auf den Starttyp „Automatisch“ ändern und ausführen.
  • Die Verbindung wird transparent im Hintergrund aufgebaut. Der Status kann im Protokoll unter
    "C:\Program Files\OpenVPN\Log\<Name der Verbindung.log>"

    eingesehen werden.

Hilfreich ist das beispielsweise für Computer die Domänen-Mitglied sind, aber an einem anderem Standort (ohne Site-to-Site-VPN) verwendet werden.

Zugangsdaten schützen

Damit die Zugangsdaten in der „pass.txt“ nicht ungeschützt für jeden sichtbar „herumliegen“, kann man der Gruppe „Benutzer“ entweder für die Datei ansich oder den „config“-Ordner das Leserecht entziehen.

Den Zugriff verweigern führt allerdings dazu, das auch der Administrator nicht mehr so ohne weiteres an die Dateien herankommt.

Eine relativ einfache Variante ist, die Vererbung der NTFS-Rechte für den Ordner „config“ zu deaktivieren und dann bei der Gruppe „Benutzer“ das Lese-Recht zu entfernen bzw. die Gruppe ansich zu entfernen.


Windows: Securepoint SSL VPN Client, pfSense-exportierte Konfiguration und Skripte

$
0
0

Bei einem Kunden mit Windows 10 streikte die OpenVPN-Verbindung zu einer pfSense. Was zunächst nach einer einfachen Sache aussah wurde dann etwas aufwendiger.

Denn auf den ersten Blick schien lediglich die Konfiguration aus dem Securepoint SSL VPN-Client gelöscht worden zu sein. Leider funktionierte es immer noch nicht, nachdem diese neu importiert wurde. Zuallererst wurde keine Verbindung aufgebaut. Nach einem Blick in den Geräte-Manager musste man feststellen das außer der üblichen einzelnen TAP-Netzwerkverbindung gleich sechs Stück vorhanden waren, woher ist leider unbekannt. Normalerweise stört das nicht, in diesem Fall räumten wir erstmal auf.

Eine Aktualisierung auf die neueste Ausgabe des Securepoint SSL VPN-Clients brachte ebenfalls keine Besserung. Testweise den Original-OpenVPN-Community-Client installiert und getestet, siehe da, es läuft. Diesen wieder deinstalliert, den aktuellen TAP-Treiber aus dem Original-OpenVPN-Setup, z.B. mit 7-Zip, extrahieren und installieren. Etwaige ältere bzw. vorige Treiber zuvor entfernen!

Das die Konfiguration nicht mehr will hängt damit zusammen, das Diese bei Änderung durch den Securepoint SSL VPN-Client irgendwie zerschossen wird. Abhilfe ist allerdings möglich, zumindest was die Einbindung von Skripte betrifft:

  • Die OpenVPN-Konfiguration importieren. Die Skripte die bei Verbindung, Trennen, etc. ausgeführt werden sollen konfigurieren.
  • Im Windows-Explorer zu „%AppData%\Securepoint SSL VPN\config\<Verbindungsname>“ wechseln.
  • Dort die Datei „scripts.conf“ kopieren.
  • Die Konfiguration aus dem Securepoint SSL VPN-Client löschen und erneut importieren ohne eine Änderung vorzunehmen!
  • Die zuvor kopierte „scripts.conf“ in den entsprechenden „config“-Ordner einfügen.

Wird nun eine OpenVPN-Verbindung aufgebaut, werden auch die Skripte ausgeführt.

Windows Server 2019 Essentials

$
0
0

Zugegeben, die abgespeckten Windows Server-Ausgaben jenseits vom Small Business Server (SBS) oder Foundation habe ich schlicht vernachlässigt. Das lag zum einen an so mancher Nachwirkung bei der damaligen Administration von SBS-Maschinen und wehe man wich von den Assistenten ab oder dem mehr oder wenigen leidigen Dashboard und Connector(en) bei den Essentials-Ausgaben sowie das so manches Produkt nicht auf einem SBS oder Essentials installieren lies. Bei Foundation klappte es hingegen erstaunlich oft bzw. gut.

Ebenfalls wenig hilfreich waren der Wink mit dem Zaunpfahl Richtung Cloud sowie die doch recht kurze Lebenszeit von so manchem Produkt für kleine Umgebungen oder wer kennt noch Windows Essential Business Server? Nach einem Hinweis von Kollegen (Hallo Jörg und alle anderen), wurde es nun doch Mal wieder Zeit, nach dem aktuellen Stand der Dinge zu schauen.

Der Windows Server 2019 Essentials gleicht eher den ehemaligen Foundation-Ausgaben statt den bisherigen Essentials-Varianten. Soll heißen (Kurzausgabe):

  • Maximale Benutzer 25 / Maximale Geräte: 50 / Keine CALs notwendig
  • Einziger Domänencontroller im Netzwerk
  • Kein Dashboard
  • Kein Connector

Im Gegensatz zu früheren Ausgaben von SBS, Foundation oder Essentials beherrscht der Windows Server 2019 Essentials die Hyper-V-Rolle und darf entweder einmal physikalisch oder einmal virtuell installiert werden! Das „oder“ im vorigen Satz ist zu beachten, beides funktioniert zwar technisch, ist allerdings Lizenzrechtlich mit einer Lizenz nicht zugelassen. Dies ist der Standard-Ausgabe vorbehalten.

Die Remote Desktop Dienste (aka Terminalserver) stehen mit Ausnahme des Lizenzierungsdienstes und des Gateway nicht zur Verfügung! Das Gateway wird zwar in der Doku erwähnt, bei einer Test-Instalaltion stand (bei mir) nur der Lizenzierungsdienst zur Verfügung. An dieser Stelle müsste man also wieder auf eine Alternative setzen.

Eine gute Übersicht der Unterschiede findet sich im Wiki von Thomas Krenn.

Installation und Administration verhalten sich wie von den Standard- oder Datacenter-Ausgaben gewohnt.

Bleibt mitunter das leidige Problem, das nicht jedes Produkt sich auf einem nicht Standard- oder Datacenter-Server installieren lässt.

Quellen:

WindowsPro –
Windows Server 2019 Essentials: Features verschwinden, Limitierungen bleiben

pfSense: OpenVPN – Für unterschiedliche Benutzer unterschiedliche Routen setzen

$
0
0

Während man für alle OpenVPN-Benutzer die Route(n) in der Server-Konfiguration im Feld „IPv4 Local Networks“ einträgt kann man mit Hilfe der „Client Specific Overrides“ für bestimmte Benutzer weitere oder andere Routen setzen.

Ein Szenario kann sein, das Anwender ins LAN dürfen und Administratoren zusätzlich noch ins Management-Netzwerk. Selbstverständlich lässt sich das zusätzlich noch mit den Firewall-Regeln steuern und das sollte auch so sein, dennoch muss nicht jeder OpenVPN-Client jede Route kennen.

Leider ist die Angelegenheit nicht ganz so trivial wie man evtl. zunächst annehmen möchte, denn trägt man nun einfach in den „Client Specific Overrides“ andere oder weitere lokale Netze ein, so wird dies zunächst nicht angenommen. Es spielt dabei keine Rolle, ob man das Feld „IPv4 Local Networks“ oder im Feld „Advanced“ „push „route <Netz> <Subnetz>““ verwendet.

Relevant ist, nach einer Änderung den OpenVPN-Dienst neu zu starten!

Die globale Route(n) ersetzen

Möchte man die Route(n) die Global vom OpenVPN-Server gesetzt werden ersetzen, so ist die Sache eine Andere. Denn für diesen Zweck muss die Client-Konfiguration angepasst werden. In der *.ovpn-Datei folgende Zeilen ergänzen:

route <Netz> <Subnetz>
route-metric 25
route-nopull

Mittels „route-nopull“ bekommt der Client keine Routen mehr vom Server „gepusht“, daher muss lokal die Route(n) gesetzt werden.

Quelle:

OpenVPN – FAQ – Overriding a pushed “route” in the client’s config throws an error

Mit Win10XPE auf die Schnelle ein Drive Snapshot-Rettungsmedium erstellen

$
0
0

Es gibt einige Wege wie man aus einer Windows-ISO, den Recovery-Medien usw. eine angepasste bootfähige Umgebung für den Notfall bauen kann.

Neben meinen eigenen Skripten im Speziellen sind in der breiten Maße vor allem das ct-Notfall-Windows bekannt. Möchte man selbst ein bootfähiges Notfall-System bauen, kann dies über die Eingabeaufforderung und einigen Befehlen erfolgen oder viel bequemer und einfacher mit einem Tool. Zur letztgenannten Gattung gehört Win10XPE.

  • Win10XPE herunterladen und z.B. nach „C:\WinPE“ entpacken.
  • Die aktuelle Windows 10-ISO herunterladen und mit „Rechtsklick – Bereitstellen“ einhängen.
  • Drive Snapshot und was man sonst noch in der Notfall-Umgebung haben möchte unter
    C:\WinPE\Win10XPE\Projects\Include\x64\AdditionalFiles\Tools

    hinterlegen.

  • „Win10XPE.exe“ starten.
  • „Select the Windows 10 source folder“ anklicken und die zuvor bereitgestellte Windows 10-ISO bzw. das virtuelle CD/DVD-Laufwerk auswählen.
  • Auf „Play“ klicken und warten bis der Vorgang abgeschlossen ist.
  • Die resultierende ISO kann beispielsweise mit Rufus auf einen USB-Stick übertragen werden.

Startet man nun die so erstellte Rettungsumgebung kann man neben den mitgelieferten Tools aus dem Explorer heraus unter „X:\Tools“ Drive Snapshot und weiteres aufrufen.

Soweit erfolgreich getestet mit Windows 10 1903 V1-ISO in 64-bit.

Hyper-V: Vorhandene *.vhd-Dateien werden nicht zur Auswahl angeboten

$
0
0

Für eine Kundin bin ich gerade dabei auf einem Windows 10 Pro 1903-Computer in Hyper-V eine Installation durchzuführen. Damit man „Die üblichen Verdächtigen“ an Tools schnell und einfach parat hat, existiert eine *.vhd-Datei die Diese beinhaltet.

Bei dem virtuellen Computer der Generation 2 wird allerdings beim Hinzufügen keine *.vhd angezeigt geschweige denn angeboten, zur Auswahl stehen lediglich *.vhdx und *.avhdx. Durch die simple Angabe von *.* oder sofern bekannt des eigentlichen Dateinamens der *.vhd kann man Diese dennoch anzeigen bzw. auswählen und einbinden.

Linux Mint: Desktop-Symbol zum Verbinden/Trennen der VPN-Verbindung erstellen

$
0
0

Auf einem Kunden-Notebook kommt Linux Mint mit Cinnamon-Desktop zum Einsatz. Damit die OpenVPN-Verbindung bequemer aufgebaut bzw. getrennt werden kann, statt immer über das Symbol des Netzwerk-Managers gehen zu müssen, wurden entsprechende Desktop-Symbole hinterlegt.

Der Netzwerk-Manager lässt sich leicht via CLI bedienen. So ist zum Verbinden mit OpenVPN nur ein neuer Starter mit folgender Befehlszeile notwendig:

nmcli con up id "<Verbindungsname>"

Zum Trennen sieht der Befehl so aus:

nmcli con down id "<Verbindungsname>"

Quelle:

30 Days of Linux (and Beyond) – Create a Desktop Shortcut to a VPN Connection

Windows 10 1903: Automatischen Neustart durch Windows Updates verhindern

$
0
0

Bis Windows 10 1809 reichte es aus, die Aufgabendatei für den automatischen Neustart zu entfernen und durch einen Ordner zu ersetzen. Bei Windows 10 1903 hat sich eine Kleinigkeit geändert.

In der Aufgabenplanung findet man die „Reboot*“-Aufgaben unter

Microsoft - Windows - UpdateOrchestrator

Dort kann man allerdings nicht allzuviel ausrichten, da man keine Berechtigungen hat. Selbst wenn man die Aufgabe(n) deaktiviert, werden dieser vom System wieder reaktiviert und ausgeführt. Ein Entfernen an dieser Stelle bringt ebenfalls wenig, da sie neu angelegt werden.

Bislang bestand der Trick darin, im Verzeichnis

C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator

die Datei „Reboot“ zu entfernen und an gleicher Stelle einen Ordner mit gleichen Namen zu erstellen. Der Trick funktioniert auch bei Windows 10 1903, nur das nach Upgrades neben der bisherigen „Reboot“-Aufgabe noch zwei weitere existieren (im Screenshot nicht zu sehen, da dieser von einer Neuinstallation stammt):

Offenbar wird „Reboot“ nicht mehr verwendet und Microsoft arbeitet an dieser Stelle, wie man anhand der Namensgebung erkennen kann, etwas granularer.

Eine Eingabeauforderung mit erhöhten Rechten öffnen und folgende Befehle ausführen:

cd C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator
del Reboot*
mkdir Reboot
mkdir Reboot_AC
mkdir Reboot_Battery

Hyper-V: Ungewollte Prüfpunkte / *.avhdx statt *.vhdx-Dateien

$
0
0

Verwendet man Hyper-V unter Windows 10 fällt einem früher oder später auf, das es statt *.vhdx-Dateien für die virtuellen Festplatte auch immer *.avhdx-Dateien gibt, obwohl man selbst keinen Prüfpunkt gesetzt hat.

Hintergrund dieses Verhaltens ist das automatisch Prüfpunkte seit Windows 10 1709 erstellt werden. Dies ist sogar die Voreinstellung bei neu angelegten virtuellen Computern. Mitunter ist das allerdings nicht gewünscht und sogar hinderlich, wenn man die virtuelle Festplatte eines ausgeschalteten virtuellen Computers direkt Bereitstellen, auch Öffnen, Einhängen oder Mounten genannt, möchte.

Diesem Verhalten kann man auf zwei Arten begegnen: Entweder man deaktiviert die Verwendung von automatischen Prüfpunkten oder man deaktiviert generell die Prüfpunkte. Beides muss pro virtuellen Computer erfolgen.

Hinweis: Auf einem Test-System mit Windows 10 1903 führte das Löschen eines Prüfpunkts keineswegs zum zusammenführen der *.vhdx mit der *.avhdx. Schlimmer noch, der virtuelle Computer konnte überhaupt nicht mehr gestartet werden. Ein Umbenennen der *.avhdx zu *.vhdx half leider nicht um an den Inhalt der virtuellen Festplatte heranzukommen.

Quellen:

Lost In IT – Hyper-V erstellt automatisch AVHDX Dateien

Microsoft Docs – Enable or disable checkpoints in Hyper-V

Microsoft TechNet – Data recover from snapshot file – AVHDX

Drive Snapshot im c’t-Notfall-Windows 2020

$
0
0

Kurz notiert: In der Ausgabe der ct 22/2019 gibt es eine aktualisierte Auflage des Notfall-Windows und natürlich ist wieder eine Spezial-Version (läuft bis Ende 2020) von Drive Snapshot mit an Bord.

Das Setup kann ohne Abo heruntergeladen und genutzt werden.

Quellen:

c’t-Notfall-Windows 2020

c’t-Notfall-Windows: Klonen und Imagen

Schnell und einfach einen USB-Stick für die Windows Server 2019-Installation erstellen

$
0
0

Im Netz finden sich einige Anleitungen wie man mehr oder weniger aufwendig einen bootfähigen USB-Stick für die Installation von Windows Server 2019 erstellen kann.

Die meiner Meinung nach einfachste Variante stellt allerdings der Einsatz von Rufus dar.

  • Das Tool herunterladen und ausführen.
  • Die ISO-Datei auswählen und auf „START“ klicken.

An den Voreinstellungen habe ich nichts verändert. Der so erzeugte Stick wird just in diesem Moment für die Installation von Thomas Krenn Microserver verwendet.

pfSense: Wiederherstellung auf Hyper-V

$
0
0

Bei einem Kunden ist (natürlich) über Nacht der VPN-Router, eine pfSense, ausgefallen. Damit möglichst schnell und ohne Vor-Ort-Einsatz das VPN wieder läuft, wurde kurzerhand auf dem vorhandenen Hyper-V auf Basis eines Windows Server 2012 R2 eine virtuelle Maschine eingerichet.

Das Vorgehen ist hier beschrieben, mit dem Unterschied das mittlerweile die nativen virtuellen Netzwerkkarten des Hyper-V unterstützt werden. Man braucht also nicht mehr die „Älteren Netzwerkkarten“ und das Skript. Ferner läuft die pfSense dort nur als VPN-Server. Virtuelle Computer der „Generation 2“ funktionieren allerdings immer noch nicht.

Soweit so gut, die Installation lief reibunglos durch, der virtuelle Computer startete anschließend ohne Schwierigkeiten und die Netzwerkkarten und IP-Adresse konnten zugewiesen sowie das Web-Interface erreicht werden.

Beim Einspielen der Datensicherung allerdings wurde schon gar nicht nach der Neuzuordnung der Interfaces gefragt und das System startete neu. Eigentlich ist der Vorgang beim Wiederherstellen auf abweichende Hardware wie hier beschrieben. Nun blieb der virtuelle Computer bei

Hypervisor: Origin = "Microsoft Hv"

hängen. Selbst nach mehreren Minuten tat sich nichts.

Also das Ganze leider reproduzierbar wiederholt. Daraufhin den virtuellen Computer nochmals neu installiert und der Reihe nach folgende Teile aus der Datensicherung wiederhergestellt:

  • OpenVPN
  • Firewall Rules
  • System

Damit waren die OpenVPN-Instanzen, die Firewall-Regeln und die Benutzer sowie weitere System-relevante Einstellungen wiederhergestellt, aber es fehlten die Zertifikate. Kurz recherchiert zeigte schnell, das deren Wiederherstellung nicht ganz so schnell und einfach möglich ist, siehe beispielsweise hier:

netgate – Backup/restore How to restore Certificates only

Aus diesem nennen wir’s mal halb-nutzbaren Zustand dann nochmals eine Wiederherstellung von „All“ durchgeführt und siehe da man wird nach dem Zuordnung der Interfaces gefragt. Beim anschließenden Neustart dauerte es zwar ebenfalls einen Moment bis

Hypervisor: Origin = "Microsoft Hv"

übersprungen war, aber es läuft.

FRITZ!Box – Unterschiedliche Benennung der Funknetze auf 2,4 und 5 GHz

$
0
0

Privat habe ich eine AVM FRITZ!Box 7490 an der Wand hängen. Bislang war diese an den Rest des Netzwerks mit einer umfunktionierten Unterputz-Telefonleitung die immerhin 100Mbit/s schaffte angebunden. Vor kurzem wurde eine neue Heimat für die FRITZ!Box ausgesucht und diese nun per CAT6-Kabel Gigabit-mässig ans Netz gebracht.

Soweit sogut. Für’s Surfen im Internet taten es bei meinem VDSL100 auch die 100Mbit/s über die Telefonleitung, beim Kopieren von Dateien war das dann mituner schon eine langwierige Angelegenheit, daher auch die neue Position samt ordentlicher Anbindung.

Dennoch wollte es zunächst nicht so recht klappen. Bei näherer Betrachtung stellte sich heraus, das in fast allen Fällen auf das 2.4 statt 5 Ghz Band zugegriffen wurde, obwohl beide gut zur Verfügung stehen.

So folgte als erste Maßnahme eine Änderung der Netzwerkkarten-Konfiguration, so das nun das 5 GHz Band bevorzugt werden sollte. Siehe dazu Windows: Bevorzugtes WLAN-Band einstellen

Damit sah die Welt zumindest kurzfristig etwas besser aus, aber rund war’s immer noch nicht, wechselte das Notebook doch immer wieder ins 2.4 GHz Band. Als nächstes dann in der FRITZ!Box die Namen der beiden WLAN-Netze differenziert, denn bislang wurde für beide Bänder der gleiche Namen verwendet. Damit unterschiedliche Namen möglich sind den Haken setzen bei „Unterschiedliche Benennung der Funknetze auf 2,4 und 5 GHz“ und entsprechend die Namen wunschgemäss anpassen.

Bis jetzt läuft es nicht schlecht, wenngleich immer wieder Unterbrechungen auftreten, die ich noch nicht eingrenzen bzw. klären konnte.

Viewing all 1839 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>