Um aus einem Verzeichnis eine ISO zu erstellen – um z.B. diese ISO dann in einer virtuelle Machine zu mounten – braucht man unter macOs nur das Terminal 🙂
Folgender Befehl generiert die ISO (hier Image.iso) aus den angegebenen Verzeichnis:
hdiutil makehybrid -iso -joliet -o /Pfad/zur/Image.iso /Pfad/zum/Verzeichnis
Ich musste einen Exchange 2013 mit installierten CU1 updaten – bekamm aber folgende Fehlermeldung:
Das Produkt mit dem Code 4934d1ea-be46-48b1-8847-f1af20e892c1 kann nicht entfernt werden. Schwerwiegender Fehler bei der Installation. Fehlercode: 1603. Letzter vom MSI-Paket ausgegebener Fehler: ‚Unable to install because a previous Interim Update for Exchange Server 2013 Cumulative Update 1 has been installed. Please use Add/Remove Programs to uninstall the Interim Update before running this setup again.‘.
Durch den installierten KB2874216 wird das Update blockiert.
Eine Entfernung bzw. Deinstallation des Updates war bei mir nicht erfolgreich bzw. lies es sich einfach nicht entfernen.
Als Workaround habe ich in der Registry den Schlüssel
HKLM\Software\Microsoft\ExchangeServer\V15\Setup\Interim Update
gelöscht.
Danach den Server rebooten – das Setup neu starten – geht 🙂
Quelle: https://anotherexchangeblog.wordpress.com/tag/kb2874216/
Mir wurde nach einem Upgrade von meiner Nextcloud 14 auf die aktuelle Version folgendes angezeigt:
Um die Datenbankoperationen mit occ auszuführen musste ich folgendes machen :
per SSH auf dem Server und in das Nextcloud-Verzeichnis (bei mir /var/www/html/nextcloud) wechseln
cd /var/www/html/nextcloud
Dann zuerst die Indizies erstellen
sudo -u www-data php occ db:add-missing-indices
Und anschliesend die Konvertierung auf big int durchführen
sudo -u www-data php occ db:convert-filecache-bigint
Danach war die Datenbank glücklich 🙂
Und man kann sich an die anderen Meldungen machen 😉
Ich hatte den Anwendungsfall, dass ich bei einer Exchange-Migration nur immer eine bestimmte Anzahl von Postfächern umziehen konnte.
Dieses Problem lässt sich wunderbar per Powershell lösen:
$a= get-mailbox -server NameDesExchangeServer | Select-Object name -First 100
foreach ($b in $a) {New-moverequest -Identity $b.name}
Kurze Erklärung: In der ersten Zeile schreibe ich die ersten 100 Zeilen der Ausgabe von get-mailbox in eine Variable.
In der zweiten Zeile übergebe ich den Postfachnamen in ein new-moverequest – und mache dies für jede Zeile.
Und schon hat man – in meinem Fall – 100 MoveRequest 🙂
Natürlich kann man hier noch bei get-mailbox oder new-moverequest noch weitere Parameter und Optionen übergeben
Quelle: TechNet
Will man seinen Clients hinter einer OPNsense-Firewall – die hinter einer Fritz!Box (hier an einem Telekom-Anschluss) hängt – IPv6-Konnektivität bieten muss man folgendes einstellen:
Auf der Fritz!Box:
1. Navigieren zu: „Heimnetz => Netzwerk => Netzwerkeinstellungen -> IPv6-Adressen“
2. Die Option setzen: „DHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren“ => „DNS-Server und IPv6-Präfix (IA_PD)zuweisen“
3. Speichern
Auf der OPNsense:
1. Navigieren zu: „Schnittstellen => WAN„:
Die Option setzen: IPv6 Konfigurationstyp: DHCPv6
2. DHCPv6 Clientkonfiguration
Folgende Optionen setzen:
Konfigurationsmodus: Einfach
Nur einen IPv6-Präfix anfordern: Ja
Prefix delegation size: 64
Sende einen IPv6-Präfixhinweis: Ja
Freigabe verhindern: Ja
IPv4-Verbindung verwenden: Nein
3. Speichern
4. Navigieren zu: „Schnittstellen => LAN„:
Die Optionen setzen:
IPv6 Konfigurationstyp: Schnittstelle aufzeichnen
und unter „IPv6-Schnittstelle aufzeichnen“
IPv6 Schnittstelle: WAN
IPv6 Präfix ID: 0
5. Speichern
Jetzt sollten die Clients hinter der OPNsense sauber ins IPv6-Netz kommen:
Und alle sind zufrieden 😉
Quelle: forum.opnsense.org
Wenn auf einem Exchange ein Postfach deaktiviert oder gelöscht wird, werden diese nicht gleich als getrennte Postfächer angezeigt.
Entweder man wartet auf den internen Wartungsplan oder man startet die Erkennung der getrennten Mailboxen selber – ganz einfach mittels Shell 🙂
Unter Exchange 2007 und 2010:
Für alle Datenbanken:
Get-MailboxDatabase | Clean-MailboxDatabase
Für eine spezifische Datenbank:
Clean-MailboxDatabase Datenbankname
Unter Exchange 2013, 2016 und 2019
Für alle Datenbanken:
Get-MailboxDatabase | Get-MailboxStatistics | Where {$_.DisconnectReason -ne $null } | ForEach { Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}
Für eine spezifische Datenbank
Get-MailboxStatistics -Database Datenbankname | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}
Jetzt muss man je nach Datenbankgröße in bisschen warten bis der Vorgang erledigt ist…
Dann kann man mit
get-mailboxdatabase | get-mailboxstatistics | Where{ $_.DisconnectDate -ne $null } |fl displayName,Identity,disconnectdate,database
sich alle getrennten und gelöschten Postfächer anzeigen lassen 🙂
Quelle: docs.microsoft.com und docs.microsoft.com
Ich wollte auf einem nginx-Server einen ReverseProxy für Exchange einrichten. Für MAPI-over-HTTP und den Zugriff von Mac-Clients hab ich mich an meine Anleitung gehalten – aber leider scheitert der Start des nginx mit der Fehlermeldung
unknown directive more_set_input_headers
Für den Teil
more_set_input_headers 'Authorization: $http_authorization'; proxy_set_header Accept-Encoding ""; more_set_headers -s 401 'WWW-Authenticate: Basic realm="exch2016.test.local"';
braucht es eine nginx-Erweiterung – das headers-more-nginx-module.
Ob das Modul installiert ist kann mittels
nginx -V
geprüft werden.
Falls es dort nicht zu finden ist kann es einfach entweder mit dem nginx-extras-Paket oder manuell nachinstalliert werden:
sudo apt-get install nginx-extras
bzw.
sudo apt-get libnginx-mod-http-headers-more-filter
Falls jetzt der Start immer noch nicht funktioniert kann es sein das die Module beim Start nicht geladen werden.
Dazu muss in der /etc/nginx/nginx.conf ganz oben (unter pid /run/nginx.pid;)
include /etc/nginx/modules-enabled/*.conf;
hinzugefügt werden.
Danach den nginx neustarten – dann sollte es gehen 🙂
Um die fünf FSMO-Rollen in einer Domäne von einem auf einen anderen Domain Controller zu verschieben hab ich früher immer das ntdsutil verwendet – aber das geht natürlich auch mit der Powershell 🙂
Zuerst zeigen wir uns am besten alle Rolleninhaber an. Dazu die AD-Powershell am Domain Controller öffnen oder die Module mit
Import-Module ActiveDirectory
importieren.
Die Rollen des Forest:
Get-ADForest domain.local | ft DomainNamingMaster, SchemaMaster
Und die Rollen der Domäne
Get-ADDomain domain.local | ft InfrastructureMaster, PDCEmulator, RIDMaster
Um eine Rolle zu verschieben muss man jetzt nur das Move-ADDirectoryServerOperationMasterRole Module im folgenden Schema verwenden:
Move-ADDirectoryServerOperationMasterRole -Identity „Ziel-DC“ Role
Also z. B. :
Move-ADDirectoryServerOperationMasterRole -Identity „dc-02“ PDCEmulator
Tipp: Man kann die Rollen auch super mit 0 – 4 abkürzen:
0 : PDCEmulator
1 : RIDMaster
2 : InfrastructureMaster
3 : SchemaMaster
4 : DomainNamingMaster
So kann man nämlich den Befehl schön verkürzen 🙂
Es reicht so z.B. ein
Move-ADDirectoryServerOperationMasterRole -Identity „dc-02“ –OperationMasterRole 0,1
Wenn mann z.B. alle Rollen auf einmal verschieben will lohnt sich das abkürzen richtig – so reicht ein
Move-ADDirectoryServerOperationMasterRole -Identity „dc-02“ –OperationMasterRole 0,1,2,3,4
statt
Move-ADDirectoryServerOperationMasterRole -Identity „dc-02“ –OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster
Danach nochmal überprüfen:
Get-ADForest domain.local | ft DomainNamingMaster, SchemaMaster
und
Get-ADDomain domain.local | ft InfrastructureMaster, PDCEmulator, RIDMaster
Falls eine der Rollen nicht verschoben werden kann – weil z.B. der alte Inhaber der Rolle nicht mehr erreichbar ist – kann mit dem Parameter -force die Übertragung erzwungen werden (wie unter ntdsutil mit seize).
Move-ADDirectoryServerOperationMasterRole -Identity “dc-02” –OperationMasterRole, DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster –Force
Selbstverständlich sollte der alte Domain Controller von dem wir die Rollen mit -Force verschoben haben nie wieder angeschaltet werden!
Ich hatte das Problem, dass nach fehlerhaften Firmeware-Upgrade ein Dell Switch – in meinem Fall ein N2048 – nicht mehr bootete und im u-boot hängen blieb. Anscheinend wurde beim Upgrade der Switch formatiert und deshalb wird keine Firmeware mehr zum starten gefunden. Folgendes war über die Konsole zu sehen:
Creating 1 MTD partitions on „nand0“:
0x000000200000-0x00000f000000 : „mtd=4“
/image1 not found!
ubifsload – load file from an UBIFS filesystem
Usage:
ubifsload[bytes]
– load file ‚filename‘ to address ‚addr‘
Wrong Image Format for bootm command
ERROR: can’t get kernel image!
Saving Environment to NAND…
Erasing Nand…
Erasing at 0x160000 — 100% complete.
Writing to Nand… done
/image2 not found!
ubifsload – load file from an UBIFS filesystem
Usage:
ubifsload[bytes]
– load file ‚filename‘ to address ‚addr‘
Wrong Image Forat for bootm command
ERROR: can’t get kernel image!
u-boot>
Um wieder einen funktionierenden Switch zu bekommen bin ich folgendermaßen vorgegangen:
1) Sich mit einem Terminal-Client der das Y-Modem Transfer Protokoll unterstützt (z.B. ExtraPutty, TeraTerm,) auf die Konsole des Switches verbinden
2) Baud-Rate auf 115200 setzten
u-boot> setenv baudrate 115200
3) Mit dem Terminal-Client mit der Baud-Rate von 115200 auf den Switch verbinden und die aktuell bzw. gewünschte Firmeware – hier runterladen – (die stk-Datei) hochladen
u-boot> loady
und mit dem Client via Y-Modem die Datei senden.
Wenn die Datei übertragen ist speichern und neustarten:
u-boot> saveenv
u-boot> reset
4) Nach dem Reboot kommt das Startmenü – dort müssen wir 4 – Load New Operational Code – wählen
Boot Main Menu
==============
1- Start Operational Code
2- Select Baud Rate
3- Retrieve Logs
4- Load New Operational Code
5- Display Operational Code Details
9- Reboot
10- Restore Configuration to Factory Defaults
11- Activate Backup Image
12- Start Password Recovery
Enter Choice# 4
5) Die gleiche Firmeware ins image2 (Active Image) hochladen:
Creating tmpfs filesystem on /mnt/download for download…done.
Current Active Image: image2
Which Image to Update Active (image2) OR Back-Up (image1)? Select (A/B): A
You selected to update Active Image image2…
Select Mode of Transfer (Press T/X/Y/Z for TFTP/XMODEM/YMODEM/ZMODEM) :Y
Do you want to continue? Press(Y/N): Y
und mit dem Client via Y-Modem die Firmeware-Datei senden.
Wenn die Datei fertig übertragen ist den Switch mittels der Option 1 – Start Operational Code – im Boot Main Menu neu starten
Boot Main Menu
==============
1- Start Operational Code
2- Select Baud Rate
3- Retrieve Logs
4- Load New Operational Code
5- Display Operational Code Details
9- Reboot
10- Restore Configuration to Factory Defaults
11- Activate Backup Image
12- Start Password Recovery
Enter Choice# 1
Jetzt sollte der Switch wieder normal booten.
6) Nach dem Boot kann man mal überprüfen ob alles passt:
console>enable
console#show version
Ich empfehle jetzt noch gleich eine Firmware auch als Backup anzulegen – dies kann aber jetzt per TFTP erfolgen:
console# copy tftp://ip.des.tftp.servers/N2000v6.5.0.6.stk backup
Jetzt hat man wieder einen wunderbar funktionierenden Switch 🙂
Quelle: Dell-Forum
Die Zeit ist in einem Active Directory extrem wichtig – so kann man sich z.B. (bei Default-Einstellungen) mit einer Zeitdifferenz mehr als 5 Minuten zwischen Domain Controller und Client nicht authentifizieren und deshalb nicht einloggen.
Der Windows Zeitdienst (W32Time) ist dafür zuständig das überall in der Domäne die gleiche Zeit ist. Alle Clients syncen mit „ihrem“ Domain Controller und die Domain Controller syncen mit dem DC der die PDC-Rolle inne hat.
Damit überall die gleiche – und am besten auch noch die richtige 😉 – Zeit ist konfiguriert man an dem DC mit der PDC-Rolle den Windows Zeitdienst folgendermaßen per Powershell:
w32tm /config /manualpeerlist:timeserver /syncfromflags:manual /reliable:yes /update
also z.B. :
w32tm /config /manualpeerlist:0.de.pool.ntp.org /syncfromflags:manual /reliable:yes /update
oder mit mehreren NTP-Servern:
w32tm /config /syncfromflags:manual /manualpeerlist:“0.de.pool.ntp.org 1.de.pool.ntp.org“ /reliable:yes /update
Danach den Windows Zeitdienst durchstarten
Restart-Service W32Time
und noch einmal syncen lassen
w32tm /resync
Mit
w32tm /query /status
kann überprüft werden ob der Sync funktioniert – fertig 🙂
Alle anderen DCs und/oder Clients der Domäne sollten sich jetzt mit dem PDC synchronisieren.
Ebenfalls mit
w32tm /query /status
kann überprüft werden ob das auch klappt.
Nach ein paar Minuten sollte auf allen Domain-Membern die gleiche Zeit sein 🙂
Quelle: blogs.technet.microsoft.com