Hallo liebe MDT 2012 Gemeinde, ich wünsche euch allen ein gutes Jahr 2013, zum Start ins neue Jahr gibt es direkt einen großen Artikel 🙂
In letzter Zeit habe ich immer mal wieder Anfragen von Leuten bekommen, die Fragen zur Microsoft SQL Datenbank und MDT 2012 hatten. Die Microsoft SQL Datenbank Funktion hatten wir uns hier ja schon angesehen. Seit der Version 2012 ist zu bemerken, dass der MDT 2012 gemessen an MDT 2010 deutlich besser auf die Microsoft SQL Datenbankserver der Version 2008/R2 klar kommt. Die Installation gestaltet sich deutlich einfach. Es bleibt noch anzumerken, das man sehr vorsichtig sein sollte mit dem SQL Server und dessen Konfiguration wenn auf dem Server noch andere produktive Datenbanken liegen ! Es macht dann durchaus Sinn lieber einen separaten SQL Server für den MDT 2012 zu verwenden.
Trotzdem ist die Konfiguration Microsoft SQL plus MDT die advanded class des freien OSD, wenn man das richtig baut, dann braucht man schon fast kein Fullsize Software Deployment Tool im Bereich der small und midsized infrastructure. Ich werde dazu mal wieder kleine casestudy schreiben. Deshalb nenne ich diese Kombi aus MDT2012 und Microsoft SQL Datenbank auch gerne MDTSQL² ;).
Wenn im TechNet nach "ZTIerror SQL MDT" sucht, dann wird man ganz unüblich fürs TechNet SEHR viele Beiträge finden die ungelöst sind....Zeit mal dagegen etwas zu machen 😉
Jetzt aber erstmal zu einem Fehler der sehr oft Auftritt, wenn man mit MDT 2012 und Microsoft SQL Server 2008/R2 (Edition ist des Microsoft SQL Servers ist dabei egal) arbeitet.
Folgende Fehlermeldung könnte man erhalten, wenn man den Client deployen will:
Die customsettings.ini wird abgearbeitet -sonst würde der Client sich nicht installieren, aber der MDT 2012 nimmt sich keine Daten aus der Datenbank, obwohl die MAC Addy usw. absolut korrekt sind.
Das weißt darauf hin, dass der MDT2012 keine saubere Verbindung zur Datenbank, bzw. dem Datenbank Server hat.
Das liegt wiederum meist daran, dass etwas mit den Berechtigung des SQL Servers nicht in Ordnung ist.
Hallo, hallo ?!? oder einfaches prüfen der Verbindung zum Microsoft SQL Server
Damit wir das überprüfen können, gibt es einen ganz einfachen Trick 🙂
Man legt auf dem Client, der nur per customsettings.ini installiert wurde - statt via SQL Datenbank- , eine Textdatei an und benennt sie im Explorer in z.B. "CONNECTION.UDL" um.
Diese startet man dann und sieht das folgende Fenster:
Im ersten Punkt klickt man dann drop down Menü und sollte eine SQL Server in der Umgebung sein der von diesem PC aus mit dem login erreichbar ist, so wird dieser dort angezeigt.
Wenn dem nicht so ist, dann weiß man das etwas nicht mit der SQL Verbindung stimmig ist.
Als nächstes checkt man denn am besten mal den Account den man für die SQL Verbindung verwendet hat...
Dazu einfach den von integrierter Sicherheit auf die benutzerspezifische Sicherheit wechseln und dort den Account und das Passwort eintragen. Diese Anmeldung erfolgt dann direkt am SQL Server
Dann auf das drop down Menü im Punkt 3 klicken, wenn alles OK ist, dann werden dort alle SQL Datenbanken zu sehen sein, die sich auf dem MS SQL Server befinden.
Wenn das nicht der Fall sein sollte, sieht das dann so aus.....
Das lässt darauf schließen, das der SQL Browser Dienst nicht gestartet ist oder das der Port 1434 (UDP) nicht offen ist.
Sollte dieser Fehler auch auftreten wenn folgende Einstellungen gesetzt sind und man sich testweise mit dem entsprechend MDT/Datenbank Service Account angemeldet hat
......dann stimmt etwas mit den Berechtigungen nicht bei dem angemeldetem Windows Konto. Hier kann es sein das die lokale Sicherheitsrichtlinie "Auf diesen Computer vom Netzwerk aus zugreifen" nicht zugelassen ist. Des weiteren sollte wir auch die Richtlinie "Zugriff vom Netzwerk auf diesen Computer verweigern" nicht aktivieren.
Noch ein Test....nochmal das ganze...aber RICHTIG
Eine andere Möglichkeit wäre, dass die Berechtigung oder die Remoteverbindung auf dem Microsoft SQL Server nicht sauber ist. Das kann man aber leicht überprüfen, in dem man einfach die MDT SQL Datenbank neu verknüpft.
Es MUSS auf jedenfall mit dieser Option weiter gemacht werden, verklicken heißt hier viel Arbeit !!
Das funktioniert gut solange alles auf dem selben Server läuft....nur für die Remoteverbindungen sieht die Sache ein wenig mehr "tricky" aus.
Hier sollte wir auf einige Fallstricke aufpassen, die das System und die Konfiguration auf dem Microsoft SQL 2008/R2 bereit:
Firewall Einstellung:
Für die kommunikation mit dem Microsoft SQL 2005/2008/R2/2012 ist der Port der freizugeben ist Port 1433 TCP. Das macht man am besten über eine GPO, dann haben alle in der Domain was davon 😉
Ich gebe den Port 1434 UDP auch immer direkt mit frei, der ist für den SQL Browser, da spart auch ne Menge Ärger 🙂
Wichtig ist für die Sicherheit, dass die Firewall Regel nur für privat und Domain erlaubt ist, NICHT für öffentlich !
Microsoft SQL Server:
Auf dem SQL Server MÜSSEN die Pipes und/oder die TCP Socks aktiviert sein, dies sieht dann so korrekt aus...
...dann sollen der Port 1433 TCP auch in den TCP/IP Einstellungen eingetragen sein (geht auch ohne aber ich trage den 1433 trotzdem immer dort ein, seit ich mich mal bei einem Deployment dusselig gesucht habe). GANZ wichtig ist das man bei "Dynamische TCP-Ports die "0" rauslöscht....sonst greift die Eingabe der 1433 nicht und die Port bleiben dynamisch.
Wenn man alle IP auf 1433 setzen will, dann diese Einstellung
Deshalb rate ich auch immer zur Verwendung von named pips, aber leider ist das Leben, beim Kunden im Feld draußen ,nicht immer ein Wunschkonzert 🙂
Entscheidet man sich für die named pipes, so muss man den SQL Share bei der DB Config angeben (als Verifizierung), sonst wird keine Verbindung hergestellt.
Nicht vergessen danach den SQL Serverdienst neu zu starten, damit unsere Änderungen auch wirken !
Wir können auch testen,ob das erfolgreich war. Ich mache das mit dem Befehl netstat -a, da bekommt man dann die Ports inkl. deren Status geliefert. Eine weitere Testmöglichkeit ist auf einem Client den Befehl telnet xxx.xxx.xxx.xxx 1433 (IP oder Hostname vom SQL Server) einzugeben. Natürlich muss dafür der Telnet Client installiert sein und wenn dann ein leeres cmd Fenster kommt, ist die Verbindung zum Microsoft SQL Server OK.
Fazit:
Wir haben jetzt hier die häufigsten Fehler, die mir so im Laufe meiner Arbeit mit MDTSQL² begegenet sind, erörtert.
Wird aber sicher nicht das letzte mal sein, das wir Fehler hier beleuchten 😉
