Autoren-Archiv: weed

Linux (SuSE/Debian/RedHat) 802.1q VLAN-Interfaces erstellen und IP-Adressen vergeben

Veröffentlicht am von — Keine Kommentare ↓

Dies ist mal wieder eine dieser „schnellen Notizen“, weil ich das jetzt ständig neu nachschlagen musste. 802.1q VLANs unter Linux werden in der Regel an ein bestehendes (physisches) Interface gebunden und stehen dann als Unterinterface mit einem Punkt (bzw. in „ip addr“ mit einem @-Zeichen) getrennt zur Verfügung.

Ein neues VLAN Interface unter Linux erstellen

Das Interface eth1 ist das physische Interface und eth1.3 wird das zugehörige VLAN-Interface (VLAN ID 3):


ip addr add 192.168.100.23/24 dev eth1
ip link set dev eth1 up
ip link add dev eth1.3 link eth1 type vlan id 3

Das Interface eth1.3 hat so noch keine IP-Adresse.

Ein VLAN Interface unter Linux konfigurieren

Das Interface eth1.3 wird mit einer IP-Adresse konfiguriert:


ip addr add  172.16.3.1/24 dev eth1.3
ip link set dev eth1.3 up

Der Netzwerverkehr für 172.16.3.0/24 passiert dann nun auf eth1.3, wird also direkt mit der VLAN ID=3 getaggt. Die Route für das Linklokale Netzwerk wird, wie bei Physischen Interfaces auch,  automatisch hinzugefügt.

Ein VLAN Interface unter Linux entfernen

Wenn man es nicht mehr braucht, kann es auch wieder gelöscht werden:


ip link set dev eth1.3 down
ip link delete eth1.3 type vlan

Exchange 2280: „Die Modul DLL C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll konnte nicht geladen werden“

Veröffentlicht am von — 1 Kommentar ↓

Problem

Nach der Deinstallation von Exchange 2010 starten IIS-Sites auf dem Server nicht mehr richtig, es werden 503-Fehler ausgegeben, Application Pools werden direkt nach dem Starten wieder beendet und im Anwendungs-Ereignisprotokoll werden sehr viele dieser Fehler protokolliert:

Log Name: Application
Source: Microsoft-Windows-IIS-W3SVC-WP
Event ID: 2280
Task Category: None
Level: Error
Keywords: Classic
Description:
The Module DLL C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll failed to load. The data is the error.

Lösung

Das Exchange-Setup fügt eine eigene Modul-DLL für Kerberos-Authentifizierungen in die IIS-Konfiguration ein, entfernt diesen Eintrag be der Deinstallation aber nicht.

In der IIS-Metabasis: C:\Windows\System32\inetsrv\config\ApplicationHost.config die zugehörige Zeile entfernen, IISReset, fertig:

<add name="kerbauth" image="C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll" />

AzCopy bricht ab „Transfer FAILED: … The client could not finish the operation within specified timeout“

Veröffentlicht am von — Keine Kommentare ↓

Problem

Bei einer Exchange zu Office 365 Migration bricht AzCopy beim Bulk-Upload der PST-Dateien zu Office 365 den Upload ständig ab. Dabei gibt es im Log die Fehlermeldung:

[2008.01.18 13:37:34.357+02:00][VERBOSE] Transfer FAILED: C:\Temp\foo.pst => https://7777723982398988.blob.core.windows.net/ingestiondata/foo.pst.
[2008.01.18 13:37:34.373+02:00][ERROR] C:\Temp\foo.pst: The transfer failed.
The client could not finish the operation within specified timeout.

Lösung

Zuerst sicherstellen, das Download AzCopy (heute ist Version 7.1.0 aktuell): https://aka.ms/downloadazcopy

Der parameter /NC:<ZAHL> bestimmt die Anzahl der Upload-Thrads. Bei (Upload-) Bandbreiten unterhalb vom 5Mbps sollten hier 3-4 Thrads reichen. In einem besondes hartnäckigen Fall war „/NC:2“ notwendig.

 

Festlegen von Google als Edge Standardsuchmaschine in einer Gruppenrichlinie (GPO)

Veröffentlicht am von — Keine Kommentare ↓

Problem

Edge sucht immer mit Bing. Wenn man etwas in die Edge Adressleiste eingibt, wenn man die rechte Maustatste drückt … immer wird in Bing gesucht. Edge ist total verbingt.

Fun-Fact: Wenn man in Bing nach „bing“ sucht, bekommt man eine Anleitung, wie man die Startseite ändert. Wenn sogar die Microsoft-KI das kapiert hat …

Lösung

Mit dem Update 1703 hat Microsoft es nun endlich ermöglich, auch wirklich brauchbare Suchmaschienen in Edge zu verwenden. Dazu setzt Microsoft auf eine Browsersteuerung durch das Opensearch 1.1 Framework.

Man braucht also:

  1. Eine opensearch.xml Datei mit passendem Inhalt
  2. Einen Webserver (der via SSL erreichbar ist)
  3. Die Anpassung der Gruppenrichlinie (GPO)

OpenSearch.XML Möglichkeit 1 – Google

Google’s OpenSearch XML URL: https://www.google.com/searchdomaincheck?format=opensearch

DuckDuckGo’s OpenSearch XML URL: https://duckduckgo.com/opensearch.xml

Ecosia (Google-Frontend mit Waldorf-Bio-Touch) XML URL: https://www.ecosia.org/opensearch.xml

Für das kleine Netz von nebenan wird das auch schon reichen. Vielleicht möchte man aber nicht, das Google jedesmal weiss wann Edge geöffnet wurde. Ist ja auch ein bisschen peinlich.

OpenSearch.XML Möglichkeit 2 – Selberhosten

In der Unternehmens IT findet sich sicher ein Intranet-Webserver mit gültigem Zertifikat. Dier benötigt nur das korrekte XML-Template mit den passenden Werten darin.

<?xml version="1.0" encoding="UTF-8"?>
   <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
   <ShortName>Google</ShortName>
   <Description>Googlen</Description>
   <Url method="get" type="text/html" template="https://www.google.de/search?q={searchTerms}"/>
</OpenSearchDescription>

(Download dieser OpenSearch XML mit Google-Query)

Anpassung der Gruppenrichlinie

Die nagelneue (1703/1709 ADMX-Updates hier) Edge-Gruppenrichlinie ist zu finden unter:

Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Windows Komponennten > Microsoft Edge > Standartdsuchmaschine festlegen