Archiv für die Kategorie „Administration“

Xenserver 6.2, Host nach Pool Join in emergency mode

Sonntag, 24. Juli 2016

Nach Join eines XEN-Host in einen Pool geht der Host in den Emergency-Mode (xe host-is-in-emergency-mode zeigt true), lässt sich nicht enablen, da XAPI nicht ordentlich hochläuft. In /var/log/xensource.log Meldungen wie:

Cannot contact master: running in slave emergency mode

Connection to master died. I will continue to retry indefinitely

Anschließend über Xencenter zwar Zugriff auf den Host, lässt sich aber nicht konfigurieren oder sonstwie aktivieren. In der xsconsole tauchen keine Management-Interfaces auf. Im Standalone (non-Pool) lassen sich diese jedoch konfigurieren. Zum entfernen aus dem Pool half nur: „service xapi stop“ auf dem betroffenen Host, „xe host-forget uuid=…“ auf dem Master, anschließend „service xapi start“ und „xe pool-emergency-transition-to-master“ auf dem Host/Client (!). Daraufhin Management-Interface neu konfigurieren.

Ursächlich ist ein synch der PCI devices im Pool (aus /var/log/xensource.log):

[debug|xen3|0 thread_zero|dbsync (update_env) D:b4254ebccd18|dbsync] Sync: sync_pci_devices

Jul 24 07:55:40 xen3 xapi: [debug|xen3|0 thread_zero|dbsync (update_env) D:b4254ebccd18|backtrace] Raised at list.ml:144.16-25 -> db_actions.ml:16810.45-98 -> xapi_pci.ml:59.14-62 -> list.ml:57.20-23 -> fun.ml:17.22-29 -> xapi_pci.ml:57.16-225 -> dbsync_slave.ml:322.2-111 -> dbsync.ml:62.7-53 -> server_helpers.ml:72.10-22

Auf dem Server Master:

xe pool-param-set uuid=… other-config:sync_pci_devices=nosync

Unterbindet ein Sync der PCI devices im Pool. Tatsächlich hatte der betroffene Host eine andere HW-Konfiguration als die anderen Member.

xenserver 6.2, debian updated auf jessie, not booting

Mittwoch, 20. Juli 2016

Nach update von Debian auf jessie bottet VM nicht.

Zuerst in HVM Virtualisierung Mode:

xe vm-param-set uuid=<vm uuid> HVM-boot-policy="BIOS order"

und von Debian Live CD in Rescue Mode gebootet. In /boot Kernels und initrd gecheckt. Grub neu installiert.

Danach in Xenserver HVM deaktiviert und pygrub aktiviert:

xe vm-param-set uuid=<vm uuid> HVM-boot-policy=""
xe vm-param-set uuid=<VM uuid> PV-bootloader=pygrub

Richtigen Kernel mit auf den Weg geben und Root-System (in meinem Fall /dev/mapper/myvg-root):

xe vm-param-set uuid=vm-uuid PV-bootloader-args=“–kernel=/vmlinuz-1234-amd64 –ramdisk=/initrd.img-123″
xe vm-param-set uuid=vm-uuid PV-args=“root=root-device  ro quiet“

Kein Loginbildschirm nach Strg+Alt+Entf in Windows 7 nach KB3097877

Freitag, 13. November 2015

Nach automatischer Installation des defekten Patches 3097877 funktioniert auf Windows 7 Computern (mit Touchscreen) der Login in der Domäne nicht mehr.

Lösung: Reparaturmodus, Regedit starten, von C:windowssystem32configsoftware die Registry laden. Ändern:

HKLM / Software / Microsoft / Windows / CurrentVersion / Authentication / LogonUI / ShowTabletKeyboard

auf 0. Danach ist der Login wieder möglich. Eine aktualisierte Version des Patches löst das Problem dann wieder und das Onscreen-Keyboard kann im Prinzip wieder aktiviert werden.

Migration SBS2003 Exchange -> Exchange 2013

Mittwoch, 2. September 2015

Auslesen von alten Mailboxen aus SBS2003 per Exmerge ( http://www.microsoft.com/downloads/en/details.aspx?FamilyID=429163EC-DCDF-47DC-96DA-1C12D67327D5& )

Stolperfalle: die exmerge.ini muss auf die lokale Sprache angepasst werden, z.B.:

LocalisedPersonalFoldersServiceName=Persönliche Ordner

LocalisedExchangeServerServiceName=Microsoft Exchange-Nachrichtenspeicher

Die user1.pst (Beispiel) auf ein Netzlaufwerk (hier beispiel: share auf fileserver) legen, das für jeden freigegeben ist. Da der folgende Import von dem „Exchange-Dienst“ mit einem Service-Konto ausgeführt wird, ist es nötig, dieses Netzlaufwerk auch für den Exchange-Computer freizugeben. D.h.: Freigabe-Eigenschaften, hinzufügen: Objektart: Computer, Nun den Exchange-Server hinzufügen.

Auf dem neuen Exchange sollte das Postfach „user1“ schon angelegt sein. Danach am einfachsten auf dem neuen Exchange Server selbst eine Exchange-Management Konsole öffnen.

New-MailboxImportRequest -Mailbox user1 -FilePath \fileservershareuser1.pst

Überprüfen des Fortschritts mit:

Get-MailboxImportRequest

Fertige Aufträge müssen manuell entfernt werden:

Get-MailboxImportRequest -Status Completed | Remove-MailboxImportRequest

Bei Importen mit großen Nachrichten kann die maximale Objektgröße ein Problem sein und der Import fehlschlagen. Vergrößern mit

Set-TransportConfig -MaxSendSize 100MB -MaxReceiveSize 100MB
Get-ReceiveConnector | Set-ReceiveConnector -MaxMessageSize 100MB
Get-SendConnector | Set-SendConnector -MaxMessageSize 100MB

Wenn die Mailboxen der User über 2GB sind, kann Exmerge nicht mehr einfach genutzt werden. Statt dessen lässt sich der Export über die Date-Option z.B. auf bestimmte Jahre eingrenzen. Später hat man dann viele PST, die zu importieren sind. Das kann automatisiert werden über:

Get-ChildItem \\fileserver\public\directorywithPST -File -Recurse | ForEach {New-MailboxImportRequest -Mailbox
mailboxuser -FilePath $_.FullName}

In diesem Fall hier lagen die PST in Unterordnern und wurden alle dem selben User in die Mailbox gespielt.

Eventuell bleibt der Import mit InProgress stehen und ein genauerer Statusreport über

Get-MailboxImportRequest | Get-MailboxImportRequestStatistics -IncludeReport | fl >report.txt

zeigt „StalledDueToCI“ an. Workaround (Indexing auf DB abschalten, danach wieder einschalten):

Set-MailboxDatabase DB -IndexEnabled:$False

RA-Micro Migration Schritte

Mittwoch, 2. September 2015

Migrationsschritte von existierendem Fileserver / SQL-Datenbank auf neue

  1. Kopie von Daten-Laufwerk (R) auf neuen Fileserver, bei Clients als Netzlaufwerk neu einbinden
  2. Alter SQL-Server: SQL Server Managment Studio: Rechtsklick auf Datenbanken->Tasks->Sichern.
  3. Überspielen auf neuen SQL-Server, dort sicherstellen: Firewall Ports (1433 TCP, 1434 UDP) offen, Admin-Account (meist „sa“) bekannt. Hier wiederherstellen aus Datei: Datenbanken rechtsklick -> Wiederherstellen
  4. Auf einem Client auf dem Netzlaufwerk die RA/Benutzer/sql.ini anpassen. Anschließend einmal RA-Micro starten (Benutzerkontensteuerung aus). Dies schreibt die ODBC-Config neu. Wieder beenden. Anschließend Supportmodul -> SQL -> Schnittstelle. Wenn hier nicht der richtige (neue) SQL-Server auftaucht, nochmal zurück. Bekannten sa User eintragen und anpassen. Nun wird RAAdmin User in SQL erstellt.
  5. Auf neuem SQL Besitzer der SQL-DB auf RAAdmin ändern.

After SBS2003 (with Unix Extensions) -> 2012R2 Update: Convert all MSSFU2x attributes to RFC2307

Mittwoch, 12. August 2015

Nach dme Upgrade von SBS2003 auf 2012R2 und vorheriger Installation des Hotfix (KB919938) wurden die Unix-Attribute (u.A. uidNumber, gidNumber etc..) auf MSSFU2x-… umbenannt. Nach der Migration sind deshalb die neuen RFC2307 Felder, die genauso heißen (uidNumber…) leer. Deshalb funktionieren möglicherweise Authentifizierungen von Unix-Systemen per LDAP nicht mehr.

So lassen sich per Powershell alle Attribute von den migrierten MSSFU2x-… Einträgen auf die vorherigen wieder umkopieren:

Get-ADUser -LDAPFilter ‚(MSSFU2x-uidNumber=*)‘ -Properties MSSFU2x-uidNumber | ForEach-Object {Set-ADObject -Identity $_.DistinguishedName -Replace @{uidNumber=$($_.“MSSFU2x-uidNumber“)}}

Hier ist „uidNumber“ natürlich auf das jeweilige zu kopierende Attribut anzupassen.

Convert Xenserver XVA single Drive to VHD for Virtualbox

Mittwoch, 12. August 2015

Pakete build-essential and libssl-dev installieren. xva-img installieren:

wget https://github.com/eriklax/xva-img/archive/master.zip

unzip master.zip

cd xva-img-master

cmake .

sudo make install

anschließend .xva datei auspacken:

mkdir vm-xyz

tar -xf xenserverexport.xva -C vm-xyz

chmod -R 755 vm-xyz

Aus dem entstandenen Ordner einzelne Raw Images ziehen:

xva-img -p disk-export vm-xyz/Ref:1234/ vm-hd1.raw

Anschließend zu VHD:

VBoxManage convertfromraw vm-hd1.raw vm-hd1.vhd –format VHD

SBS2003 -> 2012 R2 Migration, Domäne nicht verfügbar trotz FSMO Transfer, SYSVOL Replication

Dienstag, 11. August 2015

Nach dem Transfer aller FSMO-Rollen und erfolgreichem Check per

netdom query fsmo

sowie geglückter sonstiger AD-Migration scheint der „neue“ 2012R2 nicht als DC und GC zu agieren. Ein DNS Problem war es nicht. Ein

dcdiag /test:replications

zeigt jedoch, dass die Replikation verzögert ist. Grund: Das SYSVOL Verzeichnis, das zum Start des neuen DC auch repliziert werden muss, wird wegen möglichen Inkosistenzen von Datenbanken nicht repliziert. Außerdem zeigt

net shares

nicht die „SYSVOL“ Freigabe. Ferner gibt

dcdiag /v /test:Advertising /test:SysVolCheck

an, dass der DC sich nicht als GC anbietet.

Lösung:

Auf dem alten Server:

net stop ntfrs

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup
BurFlags auf D4

net start ntfrs

Auf dem neuen 2012:

net stop ntfrs

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup
BurFlags auf D2

net start ntfrs

Danach läuft die Replikation durch, das SYSVOL Share wird angelegt und der neue DC als GC hochgestuft und damit die Domäne „erreichbar“.

SBS2003 Migration -> 2012 mit Unix Extensions

Dienstag, 11. August 2015

Bei Migration von SBS2003 mit installierten Unix Extensions kommt es beim adprep-Schritt (Schemaerweiterung) auf einem 2012 zu einem Fehler, der Attributwerte betrifft. Die Lösung ist ein MS-Hotfix auf dem 2003:

https://support.microsoft.com/de-de/kb/919938

DHCP SBS2003->2012R2 migration

Dienstag, 11. August 2015

Auf dem Server 2003 in der Commandline:

netsh

dhcp

server \server2003name

export c:dhcpdatenbankbackup all

Die Datei c:dhcpdatenbankbackup auf 2012R2 transferieren. DHCP dienst stoppen, c:windowssystem32DHCPdhcp.mdb löschen, DHCP starten und dann:

netsh

dhcp

server \server2012name

import c:dhcpdatenbankbackup

Anschließend DHCP auf 2012 neu starten.