SQL Server Management Studio „.NET Framework Error“ (Unable to read the list of previously registered servers on this system)

Problem

Das SQL Management Studio (alle Versionen ab 2008) startet nicht nur noch mit einer Fehlermeldung:

Microsoft.SqlServer.Management.RegisteredServers.RegisteredServerException: Unable to read the list of previously registered servers on this system.
Re-register your servers in the 'Registered Servers' window.
Microsoft.SqlServer.Management.Sdk.Sfc.SfcSerializationException:
Deserialization operation on /RegisteredServersStore/ServerGroup/CentralManagementServerGroup has failed.

Wenn das SQL Server Management Studio dann aber gestartet ist, kann man sich zwar verbinden, sieht aber keine Inhalte. Stattdessen erscheint der Fehler

Value cannot be null.

Oder auf Deutschen Systemen:

Wert darf nicht null sein.

Lösung

Das Temp-Verzeichnis der %TEMP% Variable ist nicht gesetzt, der Paf existiert nicht oder ist nicht beschreibbar. Auf dem System auf dem ich mich grade herumtreibe konnte ich den Fehler daher schnell beheben:

mkdir %TEMP%

Office 2013 auf Office365 offline herunterladen/installieren oder im Netzwerk verteilen

OfficeSetupDas Setup für die Office 2013 Programme aus Office 365 (die Clickstream-Installation) ist sehr einfach erledigt und bei einer schnellen Internetverbindung in relativ kurzer Zeit passiert.

Wie aber installiert man mehrere Computer in einem Netzwerk? Oder einen PC mit langsamer Internetanbindung? Microsoft hat diesen Fall immerhin vorgesehen, wenn auch nicht unbedingt einfach zugänglich gemacht. Es wäre ja auch VIEL zu einfach, wenn ein Admin das Officepaket herunterladen und direkt installieren könnte *kopfschüttel*. wie auch immer, so funktioniert die Office 365 Netzwerkverteilung (neudeutsch ‚On Premise deployment‘).

Lösung

  1. Das „Office Deployment Tool for Click-to-Run“ herunterladen und den Inhalt der Datei mit 7Zip auf den deployment UNC-Netzwerkshare (\\server\foobar) auspacken. Eine Installation ist NICHT notwendig.
  2. Die configuration.xml wie folgt bearbeiten:
    <Configuration>
     <Add SourcePath="\\server\foobar\ordner\" OfficeClientEdition="32" >
     <Product ID="O365ProPlusRetail">
     <Language ID="de-de" />
     <ExcludeApp ID="InfoPath" />
     </Product>
     </Add>
     <Updates Enabled="TRUE" UpdatePath="\\dcw1\install$\office365\" />
     <Display Level="None" AcceptEULA="TRUE" />
    </Configuration>

    Es ist hier auch möglich, das Setup noch weiter anzupassen:

    1. Office-Apps von der Installation ausnehmen
    2. Office-Apps hinzufügen (Visio, Project …)
    3. Setup-Optionen (EULA, Logging …)
  3. Das Setup zum Herunterladen der Office-Click-to-Run Setupdateien auffordern (das Paket ist etwa 1.4gb groß):
    setup.exe /download <pfad>\configuration.xml
  4. Aus diesen Ordner kann man dann das Officepaket nun lokal im Netzwerk installieren:
    setup.exe /configure <pfad>\configuration.xml

Wird das Setup mit „/download“ aufgerufen, werden die Dateien auf der Netzwerkfreigabe (oder dem lokalen Laufwerk) gespeichert. Wenn das Setup dann zum Installieren mit „/configure configuration.xml“ gestartet wird, holt der Installer die notwendigen Dateien ebenfalls vom selben Ort ab. Mehr Details zu dem Tool gibt es bei Microsoft unter http://technet.microsoft.com/en-us/library/jj219422.aspx.

vmware vCenter Appliance (vCSA) Kennwort abgelaufen, vcenter Kennwort zurücksetzen

Problem

vmware-vcenter-appliance-vcsaDer Kunde (natürlich NIEMALS ein Admin :-)) hat sich ausversehen aus der vmware vCenter Appliance ausgesperrt. Das Kennwort für root ist abgelaufen. AD-Anmeldungen schlagen ebenfalls fehl. Nach einer „zu langen“ Wartezeit geht nämlich auch die AD-Anmeldung der vCSA verloren – jetzt soll das root-Konto wieder aktiviert werden.

Die Reaktivierung des Kontos und der Kennwort-Zurücksetzen Vorgang sind sich sehr ähnlich, daher hier die Anleitung für die Aktivierung eines abgelaufenen root-Kontos und das zurücksetzen des root-Kennwortes in einem.

Lösung

  1. Mit dem vSphere Client auf den Host verbinden, auf dem die vCSA läuft und die Konsole der Appliance öffnen.
  2. Wenn der GRUB Bootloader zu sehen ist, mit der Leertaste den automatischen Vorgang anhalten.
  3. Den „VMWare VCenter Appliance“-Eintrag (der erste von oben) markieren und „p“ zur Passworteingabe drücken.
  4. Das Kennwort für den GRUB-Bootloader lautet „vmware“ (Es sei denn man hat mit VAMI die Kennwörter geändert, dann ist das GRUB-Kennwort das VAMI Systemkennwort)
  5. Den „VMware vCenter Server Appliance“ Eintrag wieder markieren und „e“ zum editieren der Bootoptionen drücken
  6. Zu den Boot-Optionen hinzufügen:vcenter-server-bootoptions
    init=/bin/bash
  7. Mit „Enter“ die Änderung übernehmen und dann mit „b“ den Bootvorgang starten. Achtung, das booten direkt an die Shell geht jetzt sehr schnell (und was sich reimt war schon immer gut)
  8. Mit „passwd root“ das Kennwort für den root-Benutzer ändern
  9. vCSA Neu starten, fertig.

Um den Root-Zugang im Falle der Sperrung wieder zu entsperren, eingfach bei Punkt 8 (das ist gestartet bash-shell für die VCSA) weitermachen:

  1. Die Datei /etc/shadow bearbeiten
    vi /etc/shadow
  2. Mit den Pfeiltesten navigiert man in die „root“ Zeile, drückt „i“ für den Insert-Modus und löscht das „x“ vor dem Dollarzeichen. Damit ist Sperrung auc schon aufgehoben.
  3. Die drittletzte Zahl der Zeile ist die Anzahl der Tage für den Kennwortablauf, wenn gewünscht kann man hier die Zahl auch direkt ändern (oder löschen für „niemals“)vcenter-server-bootoptions
  4. Speichern mit ESC (insert-mode verlassen), dann den „:“ (Doppelpunkt) für die Befehlseingabe drücken und mit dme Befehl „w!q“ (dann Enter) speichern und schliessen.
  5. Neu starten, fertig.

 

Windows 2008/2008R2 DNS Server braucht viel zu viel Speicher

Problem

Der Windows 2008/2008R2 DNS-Server („dns.exe“) konsumiert ohne Ende Speicher. Der Server startet mit 120Mb, wächst auf über 400Mb und erreicht auch gerne über 1Gb RAM. Das ist für mittlere Netzwerke mit ein paar hundert PCs ein bisschen viel.

Lösung

Standardmäßig öffnet der Windows DNS-Server einen Pool von 5000 UDP sockets (2500 IPv4 und 2500 IPv6). Unter Windows Server 2008 R2 werden für jeden Port ~2.5Kb RAM allokiert, plus zusätzliche ~7.2Kb pro Empfanspuffer fällig – und es wird pro CPU ein Buffer erstellt. Auf Maschinen mit mehreren CPUs läpper sicht das schnell ordentlich zusammen:

(2.5kb x 5000 sockets) + (32 cpus/cores x 5000 sockets  x 7.2kb ) = (12500kb) + (1152000kb) = 1164500kb = ~ 1.1GB

Sinnvollerweise verringert man also die Anzahl der Sockets:

dnscmd /Config /SocketPoolSize 100

100 ist ein guter Wert (~250PCs). Die aktuelle Anzahl prüft man mit:

dnscmd /Info /SocketPoolSize

Ärgere deine Admins nicht!

Nutze nie den Google-Übersetzer im Blindflug und vertrage dich stets mit deinen Admins, sonst kann soetwas passieren:

amazon-schmierlappen

Offenbar hat Amazon-Anbieter „Naketano“ sich diesen Rat nicht zu Herzen genommen 🙂