Autoren-Archiv: weed

VMware vSphere vSwitch Portgruppe(n) und VLANs von einem Host auf einen anderen kopieren

Veröffentlicht am von — Keine Kommentare ↓

Manchmal möchte man „einfach“ alle Portgruppen von einem vSwitch auf einen anderen kopieren. Entweder auf dem selben ESXi-Host, oder auch gleich auf einen neuen ESXi. Die Inbetriebnahme neuer VMware ESXi-Hosts wird dadurch merklich schneller möglich.

Lösung

Ohne PowerShell (PowerCLI) geht’s natürlich nicht, solange man keine Hostprofile nutzt.

Das Script benötigt das VMware PowerShell PowerCLI Modul:

Install-Module VMware.PowerCLI

Und natürlich eine funktionierende Verbindung zum vCenter Server:

Connect-VIServer <VCENTER-SERVER>

Dann lässt sich mit diesen Zeilen die Konfiguration schnell kopieren:

## ESXi source / destination
$esx_s = Get-VMHost vmware3.pmd5.org
$esx_d = Get-VMHost hhvmware3.pmd5.org

## vSwitch name source / destination
$vswitch_s = "vSwitch0"
$vswitch_d = "vSwitch0"

$portgroup = $esx_s | Get-VirtualSwitch -Name $vswitch_s | Get-VirtualPortGroup | Select-Object Name, vlanid
$vswitch = $esx_d | Get-VirtualSwitch -Name $vswitch_d 

foreach ($pg in $portgroup) {
    Write-Host "Erstelle Portgruppe {0} mit vlanid {1}" -f $pg.name, $pg.vlanid
    try {
        New-VirtualPortGroup -VirtualSwitch $vswitch -Name $pg.name -VlanId $pg.vlanid -ErrorAction Stop
    }
    catch {
        "Gibt es schon"
    }
}

Adobe DC (Adobe Acrobat DC) Werkzeugleiste FÜR IMMER ausblenden (loswerden)

Veröffentlicht am von — Keine Kommentare ↓

Um diese unglaublich unnütze, nervige und ständig im Arbeitsbereich störende Werkzeugleiste ein für allemal und permanent loszuwerden, sind leider ein paar Klimmzüge notwendig.

Wer auch immer bei Adobe für dieses fieser Geschwür der PDF-Anzeigezerstörung zu verantworten hat, muss sich nun jedenfalls nicht mehr fragen warum die Mehrheit der Benutzer praktisch ausschließlich Browser zur PDF-Betrachtung nutzt. In allen 6 Jahren seitdem es diese Leiste gibt, haben noch keinen Einzigen unter tausenden Benutzer gefunden, der das Ding auch nur annähernd sinnvoll findet. Wir hören eher sowas wie „Nicht den Adobe DC, da sieht man immer nur die Hälfte.

Die schnelle Tastenkombination zum schließen der Leiste ist Shift+F4. Das hinterlässt zwar noch eine schmale „Pop-Bar“, aber man kann seine Dokumente immerhin lesen.

Es geht aber auch „richtig“.

Lösung

Die Adobe-Seiten-Werbefläche kam erst später zum Reader dazu, daher ist das ein nachträgliches Plugin. Man muss es „nur“ finden und … löschen oder umbenennen.

Die Entfernung der „Werkzeugleiste“ hat keine anderen Konsequenzen, die Werkzeuge selbst wie Stempel, Unterschrift, das Messen und so weiter funktionieren wie gehabt.

Man muss die Datei Viewer.aapp im Verzeichnis INSTALLATION\Acrobat\RdrApp\SPRACHE\ löschen (umbenennen).

Zum Beispiel (Win 11 x65 DEU) mit „Ausführen als“ natürlich als Administrator:

rename "%ProgramFiles%\Adobe\Acrobat DC\Acrobat\RdrApp\DEU\Viewer.aapp" *.aap_

Der Pfad mag im Laufe der Geschichte und je nach Sprache etwas variieren.

In Unternehmensnetzwerken bietet es sich an, den Zugriff für Benutzer einfach via NTFS-ACL zu verbieten und schon sind alle PCs „Werkzeugleistenfrei“.

Exchange Server Event ID 205 und Event ID 16025 mit „No DNS servers could be retrieved from network adapter 00000000-0000-0000-0000-000000000000“

Veröffentlicht am von — 2 Kommentare ↓

Auf einem Exchange Server gib es Schwierigkeiten mit dem SMTP („451 4.7.0 Temporary server error. Please try again later. PRX2„) und es tauchen die Ereignisse MSExchange Common 205 und/oder MSExchangeFrontEndTransport 16025 mit diesem Inhalt auf:

Es konnten kein DNS-Server vom Netzwerkadapter 00000000-0000-0000-0000-000000000000 abgerufen werden

Lösung

Exchange erforderte, dass in Optionen der Netzwerkkarte der Haken bei „Adressen dieser Verbindung in DNS registrieren“ aktiviert ist.

Wenn man den Haken wieder setzt und „mal eben“ die Transporservices neu startet mag der SMTP auch wieder richtig mitspielen.

Restart-Service *transport*

Excel ändert selbstständig alle Links in Arbeitsmappen

Veröffentlicht am von — Keine Kommentare ↓

Man speichert „jahrelang“ Excel-Dateien auf dem Netzlaufwerk, hat dort jede Menge Links auf andere (Netzwerk-)Dateien gesetzt alles funktioniert wunderbar. Doch plötzlich gibt es beim Klick auf die Links nur noch Fehlermeldungen, nicht geht mehr.

Es erscheint statt der Dokumente ein „Sicherheitshinweis“ und vermeldet „Office hat ein potentielles Sicherheitsrisiko erkannt“. Außerdem sei „Dieser Speicherort ist möglicherweise nicht mehr sicher“.

Vorweg: Links in Excel-Dokumenten zu anderen Dokumenten sind (außer in Web- oder SharePoint Dateien) nicht absolut. Die Links bleiben also nicht bei dem was man manuell hinterlegt, sondern werden „verwaltet“. Excel versucht anhand eines Regelwerkes die Links „funktional“ zu halten und ändert beim Speichern gerne „mal eben“ alle Links des Dokumentes entsprechend ab.

Was ist das? Links zu Dokumenten auf Netzlaufwerken sind auf einmal „geändert“?

Das „Regelwerk“ das Excel nun dazu nutzt ist zum Glück ganz gut dokumentiert:
https://support.microsoft.com/de-de/topic/beschreibung-der-linkverwaltung-und-speicherung-in-excel-46628e8d-2cd6-db5f-3474-f8d7144b09d6

Ein wahrscheinliches Szenario das wir schon öfter gesehen haben könnte also zum Beispiel so aussehen:

  • Es gibt ein Netzlaufwerk X: das von \\Server\Share\Folder verbunden ist
  • Es gibt Links in einer Arbeitsmappe dort und das Dokument wird stets dort bearbeitet
  • Man öffnet die Datei vermeintlich von dort
  • Man speichert die Datei wieder dort
  • Oh nein! Alle Links sind geändert und stehen plötzlich auf Profilpfaden (%appdata%\local\Folder) oder dem Systemlaufwerk (C:\Folder)

Das, also der „Link-Verlust“ (das Phänomen nennt sich neudeutsch auch „Link-Loss“) passiert immer wenn:

  • Das Dokument (=der PC) zwischen durch „Offline“ war und Windows die Datei im Offlinecache bearbeitet hat. Der liegt nämlich auf c:\ (siehe CSC)
  • Die Datei mal „kopiert“ wurde, zum Beispiel auf einen USB-Stick oder den Desktop (C:\ oder f:\ …)
  • Die Datei via UNC-Pfad geöffnet wurde (\\Server\Share\Folder\Datei.xlsx)
  • Die Datei wurde automatisch zwischengespeichert (Default: 10 Minuten). Das passiert (Default) in %appdata%\roaming\microsoft\excel

In diesen Varianten findet Excel keinen Referenzort der Datei mehr zum relativen Pfad des geöffneten Dokumentes und ändert aus „Sicherheits- und Komfortgründen“ alle Pfade. Allerdings erst beim speichern, solang das Dokument noch geöffnet ist, ist die „zukünftige“ Änderung nicht sichtbar.

Lösung

Es gibt keine „richtige“ Lösung. Links in Excel-Tabellen sind supergefährlich. In dem Moment in den Man Daten (wie z.B. Links) in einer Tabellenkalukation verwendet, ist etwas schief gelaufen, Daten verwaltet man in Datenbanken (z.B. Access).

Aber: man kann das Problem etwas einzuschränken. Das geht natürlich auch per GPO.

  • „Automatisches Speichern“ komplett deaktivieren
  • Unter Optionen/Speichern -> Automatisches Speichern den standardmäßigen Speicherort auf den (relativen!!) Pfad des Dokumentes ändern. Je nach Anzahl der Netzlaufwerke ist es natürlich unsinn, bei jeder Datei den Ort immer wieder zu ändern.

Excel (und alle anderen Office-Apps) speichern alle 10 Minuten die aktuellen Dateien. Das ist auch sehr gut so, denn wenn eine Office-App mal abstürzt oder der Datei-Handle verloren geht (Standy, Docking-Station, WLAN-Wechsel, Windows-Updates, USB-Stick Backup, Netzwerktrennung …) wird man ja von der „letzte bekannte Version“ begrüßt. Selbige kommt genau daher.

Uptime von Aruba/HPE/ProCurve Switches anzeigen

Veröffentlicht am von — 1 Kommentar ↓

Und schon wieder ein Fall von „Notiz an mich selbst“. Jedesmal google ich nach dem Befehl für die Uptime von Switches … vermutlich jetzt nicht mehr. Die „uptime“ ist in der SYSINFO, also in der Lokalen System-Information Tabelle enthalten. Die gibt’s per SNMP und natürlich auch am CLI, also an der Console.

Uptime von ProCurve Switches anzeigen

show system-information

Und so sieht die Ausgabe von system-information aus: