Archiv

Archiv für die Kategorie ‘KixTart Scripts’

Windows 7 und Kixtart Problem – Lösung per Registry

12. Januar 2010 2 Kommentare

Windows 7 und Kixtart Problem – Lösung per Registry
Windows 7 und Kixtart Scripte machen doch oftmals Probleme, welche sich leider auch nicht mit der aktuellen Kixtart Version 4.60 lösen lassen. Meist läuft das Script einfach nicht, ohne dabei jedoch Fehlermeldungen auszuspucken! Bei mir ein ein kleiner Trick geholfen, ein zusätzlichen Eintrag in die Registry der betreffenden Windows 7 Clients:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001

Geholfen hat dies meinen Kixtart Scripten zumindest auf der Windows 7 Professional Variante (32 Bit sowie 64 Bit) und auf dem Windows 7 RC, sprich Windows 7 Ultimate.
Den obligatorischen Reboot natürlich nicht vergessen! In den Weblinks habe ich den Registry Eintrag für Kixtart auf Windows 7 noch einmal als downloadbare .REG Datei (zipped) abgelegt, falls jemand das ganze gern per GPO ausrollen möchte (was ich nur empfehlen kann!)
Weblinks:

Windows Logon Script mit Kixtart

Hier mein Kixtart Logon Script für Windows Domänen. Geschrieben in Kixtart, berücksichtigt sind für den Endbenutzer verständliche Fehlermeldungen, eine Begrüßung des Benutzers mit Namen, Hinweisen auf den Helpdesk, Laufwerksmapping, Druckermapping und gruppenbasierte Shares. Zusätzlich für Administratoren spezifische Aktionen, wie WSUS Registry Einstellungen setzen etc., zzgl. ein wenig Humor bei der Begrüssung ;)
Für das Loginscript mit Kixtart hatte ich ja eine Fortsetzung versprochen, die will ich dann auch mal liefern. Im Teil 2 beschäftige ich mich erstmal mit der Dokumentation des Scriptes aus Teil 1, wobei ich ein paar Fehler (die beim kürzen des Scripts entstanden sind) gleich mit ausbügel und einiges ergänze. Wenn jemand also das Script verwenden möchte, nehmt diesen Teil!!!

Ich habe Teil 1 offline genommen um Fehler zu vermeiden, warum sollten inkorrekte Informationen online bleiben?

Ganz zu Anfang habe ich noch eine Zeile aus der Entwicklung des Scriptes stehen, jedoch auskommentiert – das Debugging. Wenn man am Script bastelt und etwas nicht funktioniert, empfiehlt es sich diese Zeile einfach wieder aktiv zu stellen.

?View Code KIXTART
1
;BREAK ON ;*** for testing purpose only - Default is BREAK OFF

Im nächsten Teil habe ich die Gliederung der einzelnen Abschnitte des Loginscripts untergebracht. Angefangen mit ein wenig Obtik und Kommentierung, gefolgt von der Definition wie mein Loginscriptfenster aussehen soll.
SETCONSOLE(“show”) sorgt erstmal dafür das generell etwas angezeigt wird, SETCONSOLE(“maximized”) sorgt für “Vollbild” – allerdings nach “Windows Commandline Definition”, also nur in der Höhe maximiert, in der Breite jedoch auf 80 Zeichen beschränkt.
Über SETTITLE(“Anmeldeskript #### Firmenname #### v1.0″) definiere ich den Fenstertitel, hier kann man sich frei austoben, ich bau immer gern eine Versionnummer des Scripts und den Firmennamen ein.
Zum Schluß folgt die SUB Reihenfolge für die einzelnen zu durchlaufenen Unterabschnitte.

?View Code KIXTART
1
2
3
4
5
6
7
8
9
10
11
12
13
;********************************
;* main
;********************************
SETCONSOLE("show")
SETCONSOLE("maximized")
SETTITLE("Anmeldeskript #### Firmenname #### v1.0")
GOSUB "GREETING"
GOSUB "GET_OS"
GOSUB "DRIVES"
GOTO "END"
;********************************
;* end main
;********************************

SUB Begrüßung
Da ich ein Freund der Höflichkeit bin, begrüßt der Client den sich einloggenden User erstmal. Dafür werden zu Anfang in den Zeilen XX bis XX die Farben gesetzt und zwei Boxen erzeugt, in welchen der User ein paar Grundlegende Informationen zu sich selbst, zum Server und zum Netz findet. Über die kleine Reihe IF-Abfragen wird eine zur Tageszeit passende Begrüssungsfloskel ausgesprochen.
In der unteren Box findet der User die besagten Informationen, inklusive der Kontaktdaten des zuständigen Administrators, für den Fall das es Probleme gibt und der User die Durchwahl des Admins nicht im Kopf hat. Der Befehl AT gefolgt von den Koordinaten eignet sich ausgezeichnet für die Ausgabe der Informationen innerhalb der Boxen, da hier die Position des Textes innerhalb des Fensters sehr schön gesteuert werden kann, Stichwort Haptik!

?View Code KIXTART
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
;********************************
;*** Begrüßung
;********************************
:GREETING
small
Color g+/c+
BOX (3,5,20,73,FULL)
color b/c+
IF @TIME > 00:01:00 AND @TIME < 05:00:00
	AT ( 5,8) "Die Sonne ist noch nichtmal aufgegangen, aber Sie"
		 AT ( 6,8) "@FULLNAME, Sie sind schon da"
ENDIF
IF @TIME > 05:00:00 AND @TIME < 11:00:00
	AT ( 5,8) "Guten Morgen @FULLNAME,"
ENDIF
IF @TIME > 11:00:00 AND @TIME < 14:00:00
	AT ( 5,8) "Guten Tag @FULLNAME,"
ENDIF
IF @TIME > 14:00:00 AND @TIME < 17:00:00
AT ( 5,8) "Guten Nachmittag @FULLNAME,"
ENDIF
IF @TIME > 17:00:00 AND @TIME < 20:00:00
AT ( 5,8) "Guten Abend @FULLNAME,"
ENDIF
IF @TIME > 20:00:00 AND @TIME < 00:01:00
AT ( 5,8) "Es ist sehr spät @FULLNAME,"
ENDIF
		 color n/c+
		 AT ( 8,8) "Sie haben sich soeben am Netzwerk der Firma"
		 AT ( 9,8) "Firmenname angemeldet."
		 AT ( 11,8) "Die aktuelle Uhrzeit: @TIME"
		 AT ( 12,8) "Ihr Benutzername:	 @USERID"
		 AT ( 13,8) "Angemeldet an Server: @LSERVER"
		 AT ( 15,8) "Viel Erfolg und frohes Schaffen."
		 AT (17,8) "Sollte es irgendwelche PC Probleme geben, rufen Sie den"
		 AT (18,8) "PC Support:			  BAfH"
		 AT (19,8) "Telefondurchwahl:	  007"
		 color n/w+
		 AT (21,8) " "
RETURN

SUB GET_OS
In der zweiten Untersektion wird noch etwas für die oben erwähnte Infobox gesammelt, unter anderem Informationen über das auf dem Client verwendete Betriebssystem. Hier findet sich auch noch eine CASE Abfrage in der man bei Bedarf betriebssystemabhängige Operationen starten kann. Ich habe als Muster hier bei allen Betriebssystemen die Variable $ADready befüllt und die Zeitsynchronisation angeworfen, da in einem Active Directory die richtige Uhrzeit (wobei der AD Controller “richtig” definiert) sehr wichtig ist. Nachfolgend werden die gesammelten Informationen in die Infobox eingetragen. Auch hier kommt wieder der AT Befehl zum Einsatz.

?View Code KIXTART
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
;********************************
;*** Betriebssystem abfragen, Flag und ggfls. Time setzen
;********************************
:GET_OS
IF INSTR (@ProductType, "Windows NT Workstation") = 0
		 ? "Sie verwenden Windows NT"
		 $ADready = False
ELSE
		 Color g+/c+
		 BOX (23,5,30,73,FULL)
		 color b/c+
		 SELECT
		 CASE INSTR (@ProductType, "Windows 2000") > 0
				  $ADready = True
				  SETTIME "@lserver"
		 CASE INSTR (@ProductType, "Windows XP") > 0
				  $ADready = True
				  SETTIME "@lserver"
		 CASE INSTR (@ProductType, "Windows Server 2003") > 0
				  $ADready = True
				  SETTIME "@lserver"
		 ENDSELECT
		 IF $ADready = False
			 SETTIME "@lserver"
		 ENDIF
		 AT ( 24,8) "Client Name:	  @HOSTNAME"
		 AT ( 25,8) "Betriebssystem:   @ProductType"
		 AT ( 26,8) "IP Adresse:	   @IPADDRESS0"
		 AT ( 28,8) "Profilpfad:	   @HOMESHR"
		 AT ( 29,8) "Homeverzeichnis:  @HOMEDRIVE\"
		 AT ( 35,8) " "
ENDIF
RETURN

SUB DRIVES
Das mappen der benötigten Laufwerke und Drucker ist wohl mit die wichtigste Aufgabe eines Loginscripts, aber auch der Teil welcher das Script oftmals extrem unübersichtlich werden lässt. Ich habe von daher mir Unterscripte geschrieben, in welchen dann nur die Mappings stehen. An mein Hauptscript muss ich also selten ran.

Die erste Ausnahme bilden die restlichen zwei NT Clients die hier im Netz stehen (bitte nicht hänseln, die Software da will absolut nicht auf 2000 oder XP laufen....). Da die NT basierten Systeme keine UNC Pfade mit Angabe eine Verzeichnisses als Pfad unterstützen, gibt es bei mir spezielle Freigaben für NT, welche nicht auf Beispielsweise \\SERVER\Allgemein\Anträge zeigen, wobei "SERVER" der Name des Servers ist, "Allgemein" für den Namen der Freigabe steht und "Anträge" ein Verzeichnis innerhalb der Freigabe "Allgemein" ist. NT könnte das nicht verstehen, also gibt es für die NT Clients da eine Extrafreigabe, aber eben NUR da! Diese steht in diesem Script dann inder Datei "map_global_nt.kix".
Für alle anderen Betriebssysteme gilt die Datei "map_global.kix". Administratoren brauchen naturgemäß zusätzliche Freigaben, Adminfreigaben - diese werden über die Funktion IF INGROUP("Domain Admins") gemappt, denn wenn der sich einloggende Benutzer in der Gruppe Domain Admins ist, wird über den Befehl CALL "map_admin.kix" die Datei mit den Adminmappings aufgerufen. In den nachfolgenden Zeilen setzte ich zur Sicherheit gleich nochmal die Registryeinstellungen für meinen WSUS Server und starte ein manuelles Reporting an den WSUS. Sehr praktisch, denn so brauch man sich nur auf einem Client einloggen und bekommt darüber schnellstmöglich alle Updates etc. auf den Client. Ganz nebenbei wird die Funktion SHELL "command" zum Aufrufen von Konsolenbefehlen und externen Batches gezeigt ;)

?View Code KIXTART
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
;********************************
;*** Shares &amp;  Co
;********************************
:DRIVES
IF INSTR (@ProductType, "Windows NT Workstation") > 0
         CLS
         IF INGROUP("Domain Users")
             CALL "map_global_nt.kix"
         ENDIF
         ? + @ProductType
ELSE
         IF INGROUP("Domain Users")
             CALL "map_global.kix"
         ENDIF
         IF INGROUP("Domain Admins")
             CALL "map_admin.kix"
             SHELL "regedit /s \\wsus-server\ClientReg\WSUS_Client.reg"
             IF @ERROR = 0
                           Color r+/w+
                           ? "WSUS Registry Eintrag gesetzt, starte Reporting!"
                           SHELL "wuauclt.exe /reportnow"
                           SHELL "wuauclt.exe /detectnow"
                           color n/w+
                  ELSE
                           Color r+/w+
                           ? "ERROR: WSUS Registry Eintrag NICHT gesetzt!"
                           color n/w+
                           sleep 60
                  ENDIF
         ENDIF
         IF INGROUP ("Domain Users")
                  CALL "map_drives.kix"
         ENDIF
ENDIF

SUB END
Beenden muss ich das Script natürlich auch, aber wenn möglich sauber. Also eine kleine extra Sektion zum beenden des Scripts, damit ja nix schief gehen kann.

?View Code KIXTART
1
2
:END
EXIT

Die map_*.kix Dateien
Der Inhalt der Datein für die Laufwerkmappings ist denkbar einfach. Entweder man verwendet über SHELL die normalen Befehle von Windows, oder über USE Q: “\\SERVER1\USERS” beispielsweise den Kixtart Befehl dazu. Für Drucker gilt das entsprechend, Windows befehlt oder

Wenn man noch ein wenig Info an den User aufgeben möchte, was gerade so passiert, kann man dies lesbar über

?View Code KIXTART
1
2
3
4
If ADDPRINTERCONNECTION ("\\"+$PrintServer+"\LaserJetColor") = 0
     ? "Drucker Farblaserdrucker wurde verbunden"
ELSE
     ? "FEHLER beim verbinden vom Farblaserdrucker"

lösen. So kann einem ein User auch gleich am Telefon mitteilen was beim Login nicht geklappt hat und man muss nicht raten, sondern kann sich direkt an die Problembehebung machen.

Wer nun noch bei dieser Gelegenheit alles inventarisieren möchte, kann dies auch tun. Am besten dazu den Artikel auf administrator.de anschaun.

Für weitere Fragen stehe ich gerne zur Verfügung - einfach per Kommentar fragen, ich freue mich über jeden ernstgemeinten Kommentar.

Das ganze Kixtart Logon Script zum download steht in den Weblinks, allerdings ohne die Kommantare in diesem Artikel!

Abschließend noch einige interessante Links zum Thema Kixtart und Logonscripts:

Logon Script: PopUp Fenster bei Fehlern mit KixTart

Nichts ist schlimmer als wenn ein Logonscript Fehler ausgibt, die benutzer diese allerdings nicht an den Administrator weitergeben, weil sie sich die meldung nicht gemerkt haben, oder garnicht wussten das beim Login ein Fehler aufgetreten ist.

KixTart kann im Rahmen eines Logonscripts jedoch PopUp Fenster generieren, in denen dann die Fehlerbeschreibung steht und der User natürlich aufgefordert wird sofort den zuständigen Administrator zu verständigen. Im Rahmen eines Druckermappings könnte das so aussehen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$PRINTSERVER = "192.168.100.10"
$PRINTERNAME = "Farbdrucker_Raum_12"
If ADDPRINTERCONNECTION ("\\"+$PRINTSERVER+"\"+$PRINTERNAME) = 0
    ? "Drucker Druckername wurde verbunden"
ELSE
    ? "FEHLER beim verbinden vom Druckername"
	$MsgStr = "Bitte den Administrator verständigen!@CRLF"
	+ "Die Fehlermeldung lautet:@CRLF"
	+ "@CRLF"
	+ "Drucker: "+$PRINTERNAME + "@CRLF"
	+ "Server:  "+$PRINTSERVER + "@CRLF"
	+ "Fehlermeldung: "+ @SERROR + "@CRLF"
	+ "Fehlercode:    "+ @ERROR
	$Title = "FEHLER: Druckername nicht verbunden"
	$X MessageBox( $MsgStr, $Title, 4096 )
ENDIF

Ein paar Anpassungen muss man immer je nach Umgebung vornehmen, aber es soll in diesem Beispiel ja nur die generelle Funktion erklärt werden.
Über Kommentare freue ich mich natürlich immer sehr, speziell wenn meine Scripte irgendwo zum Einsatz kommen – die Firma muss natürlich nicht genannt werden!

Logon Script: Drucker verbinden mit KixTart

Einen Netzwerkdrucker zu verbinden, gehört zu den normalen Aufgaben eines Logonscripts. Via Kixtart geht das auch ganz einfach, wenn nicht noch einfacher als mit den guten alten “net use” Kommandos:

1
ADDPRINTERCONNECTION ("\\"+$PrintServer+"\Druckername")

Mit etwas mehr Code kann man gleich ein Errorhandling einbauen, welches dann auch ausgibt ob alles geklappt hat. Wahlweise entweder direkt im Scriptfenster, oder in ein Logfile, je nachdem wie man sein Loggig geregelt hat.

1
2
3
4
5
If ADDPRINTERCONNECTION ("\\"+$PrintServer+"\Druckerfreigabename") = 0
     ? "Drucker Druckername wurde verbunden"
ELSE
     ? "FEHLER beim verbinden vom Druckername"
ENDIF

Die Variable “+$PrintServer+” sollte hierbei automatisch gesetzt werden, alternativ kann man, um auf Nr. Sicher zu gehen, den Printserver entweder direkt angeben, oder selbst mit einer eigenen Variablen arbeiten.

Schnellere Updates über den WSUS 3.x

18. September 2008 Keine Kommentare

Wer schneller seine Updates von WSUS Server beziehen möchte, sollte sich folgendes Script ansehen:

?View Code KIXTART
1
2
3
4
5
6
7
8
9
10
11
; Sicherheitshalber den WSUS per Registry einmal eintragen
; Schritt 1:
; Setzen des WSUS Eintrages in die Registry
SHELL "regedit /s \\wsus-server\ClientReg\WSUS_Client.reg"
; Schritt 2:
; Schnelles Reporten an den WSUS Server initialisieren...
SHELL "wuauclt.exe /reportnow"
; Schritt 3:
; WSUS sofort nach Updates zum aktuellem Client befragen und
; diese sofort beziehen / downloaden...
SHELL "wuauclt.exe /detectnow"

Ich setze hier im Script zu allererst den Registriereintrag für den WSUS Server, das ist mir immer allemal lieber, als mich auf Cookies oder ähnliches zu verlassen.

Anschließend wird sofort ein Reporting an den WSUS Server ausgelöst, statt dies der “Willkür” des Clients zu überlassen, der aktuelle Patchstand des Clients wird also adhoc gesammelt und an den WSUS übertragen.

Im drittem Schritt wird geschaut, ob der WSUS Server Updates für den Client hat – und diese werden dann auch entsprechend der Richtlinien sofort geladen und installiert.

Das Script hat sich in der Praxis sehr bewährt, vor allem wenn viele Notebookbenutzer in der Domäne sind, welche ur ab und zu mal im Büro vorbeikommen und somit relativ schnell die Updates auf ihren Rechnern brauchen. Verbesserungsvorschläge sind natürlich immer willkommen!