#67708 - 2002-10-05 12:54 AM
Re: Deployment of Kix Scripts
|
Kdyer
KiX Supporter
   
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Update.
{Edit - The Infrastructure Master piece was not worded properly}
I apologize for not getting back on this until now, but things are looking great!
Issues/Hurdles with this upgrade:
- Two Login scripts, for two companies logging into the same domain
- Kix3.63 already in the Enterprise
- GETTYPE.EXE and other Resource Kit utilities were not working
properly. - Files to be distributed were making the NTLOGON.BAT and related
files convoluted - Parent Company (Company A) Users were not only using the NTLOGON.BAT
file but a secondary Batch file as well. - Child Company (Company B) Users were running scripts from the client
workstation and not the Logon Server. - Groups were not be detected properly, we have added in a the “token
cache” flush - http://helpdesk.kixtart.org/KixManual2001/Reference/GroupMembership.asp Also, we encountered an issue with the Infrastructure Master in the company.com domain. Variety of users- Locked down
- Full Administrative Access
- Domain Admins
- Servers
- Terminal Server/Citrix
Design Philosopies/Concepts: Ability to write to directories/folders In theory, all users should be able to write to %windir% and not %windir%\system32, however it was discovered that one of our test users could not write to %windir%. Because of this, we chose to create a folder on the same drive on the root, called Scripts.
Ability to write to the Registry Tried to make the scripts only write to HKEY_CURRENT_USER. HKEY_LOCAL_MACHINE needs Administrative access
Delivery of the Kixtart Executable Chose to use a package delivery method to copy the Kix32 to the client workstations. We are using methods and package tool described at - http://home.wanadoo.nl/scripting/
This is also discussed at - .KIX -> .EXE: Package and compact your script...
This is from Microsoft and is using the Iexpress Package tool.
This is available from - http://support.microsoft.com/default.aspx?scid=kb;en-us;Q237803 and the IDK99.EXE is available at the web location listed.
When investigating this install package script for Kixtart, it was writing to the C: Drive specifically. Worked with the Developer of the Package on Kixtart and asked him to modify the script as the maybe times where Windows is installed on another drive other than C: like M: for example. With suggestions from myself and another Moderator on http://kixtart.org for changes, he has since changed the install script to look for where Windows is installed.
The suggestions the other Moderator made was it is unnecessary to copy over the DLLS and related files for Windows 9x onto a Windows NT-Class system (Windows NT, 2000, XP)
This script has been modified and the install script to have it check for the $SystemDrive + “\Scripts” and if needed create the folder and copy appropriate files. Also, changed to not add in the Kixtart Association for .KX, .KIX, and .SCR files in the User’s Registry. When this install package runs, it creates two log files, one in the root of the Windows Drive and one in the Scripts Folder on the Windows Drive. These log files are helpful to see if the client workstation installation was successful. Additionally, these files can also be used at login to Deploy/Update Kixtart to the client workstations.
Script conversion We have two domains… A “parent” and a “child.” We have embarked on a domain migration to the child domain.
To start, we created a test script for Domain Admins and people in IT to test and hammer out any kinks. This was also called from a separate Ntlogon.bat called NTTest.bat and we modified the users testing this script. The basis of this new NTLOGON.BAT file is from - http://support.microsoft.com/default.aspx?scid=kb;en-us;Q318689
The updated NTLOGON.BAT file is:
code:
::@Echo OFF
:: LAST EDITED; kld 10.04.02 @10:38PM pst :: Trimmed down to use less stuff.. :: - From: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q318689 :: 3 October 2002 - Changed to Kixtart 4.02
@ECHO off ::SETLOCAL
VER | find "NT" > nul IF not errorlevel 1 GOTO Win_NT
VER | find "2000" > nul IF not errorlevel 1 GOTO Win_NT
VER | find "XP" > nul IF not errorlevel 1 GOTO Win_NT
VER | find "98" > nul IF not errorlevel 1 GOTO Win_9X
VER | find "95" > nul IF not errorlevel 1 GOTO Win_9X
GOTO unknown_os
:win_NT @TITLE Company A / Company B NT Logon Script ECHO HELLO %USERNAME%! Echo Welcome to %USERDOMAIN%, Inc. NT Domain Environment if not exist %SystemDrive%\Scripts\nul md %SystemDrive%\Scripts if not exist %SystemDrive%\Scripts\kix402.ok %LOGONSERVER%\NETLOGON\Programs\kix402update.exe /q %SystemDrive%\Scripts\kix32.exe %LOGONSERVER%\NETLOGON\Kixtart.kix /f :: -- call should be reserved for calling another batch file ::%windir%\kix32.exe %LOGONSERVER%\NETLOGON\Kixtest.kix goto end
:win_9X :: --- CHECK FOR FILES TO SET THE USER NAME IF NOT EXIST %WINDIR%\PUTINENV.EXE XCOPY \\EOS\NETLOGON\Programs\Win9x\PUTINENV.EXE %WINDIR% IF NOT EXIST %WINDIR%\WINSET.EXE XCOPY \\EOS\NETLOGON\Programs\Win9x\WINSET.EXE %WINDIR%
:: --- SET THE Environment Variables :: -- Execute the script ::%WINDIR%\SYSTEM\KIX32.EXE %WINDIR%\SYSTEM\W95ENV.KIX
%WINDIR%\PUTINENV.EXE L %WINDIR%\winset computername=%COMPUTERNAME% %WINDIR%\winset username=%USERNAME% %WINDIR%\winset LANGROUP=%LANGROUP% %WINDIR%\winset LOGONSERVER=%LOGONSERVER%
:: --- DISPLAY THE USER NAME/DOMAIN ECHO HELLO %USERNAME%! ECHO Welcome to %LANGROUP%, Inc. Windows 9x Domain Environment
if not exist c:\scripts\nul md c:\scripts if not exist c:\scripts\kix402.ok %0\..\Programs\kix402update.exe /q %0\..\kix32.exe %0\..\kix95.kix goto end
:unknown_os :end
The Kixtart Script is too large for posting in this article, but is generally constructed as follows:
- Set some Global Variables for Registry Keys
- If a member of Company B, do some drive mappings
- Detect the OS
- If one of the Citrix Servers for Company B, GOTO specific section
and check for ODBC, environment information and then leave - If logging into one of the servers, leave the script
- If a member of Company A, copy some files to the client workstation
- Check for files on the workstation
- Detect what version of VirusScan, Dat, Engine, and etc. being
reported from McAfee. - Check to see if ePO (ePolicy Orchestrator is installed)
- Determine what time of day it is
- Build the screen for the user to let them know what is going on
- Do some common routines for all users
- Detect which subnet the user is logging in from, if from our VPN
subnets leave - Detect which groups the users are in and map drives and run routines
for the users - Routines used in Groups listed in the previous bullet
We kept copies of script changes in folders under the Netlogon folder and each is called scriptbak and from each day changes were made; we called the folder 10042002-orig for the folder name. Sort of a “poor mans” Visual SourceSafe. This Test script was a testing ground to have both companies’ scripts to be integrated into one script.
Once we have started migration to the new domain, we took the script in the Parent Domain and looked at user groups and checked to see if they exist in the Child Domain and added notes for each group as such. Any groups that were Domain specific were prefaced with either “Parent\GroupName” or “Child\GroupName.” Groups that exist in both domains did not need to be prefaced, for example “GroupName.” This operation was then duplicated for the Child Domain Kix Script.
The “Test” Script was copied to the Child Domain.
Integrated the Child Domain Kixtart.KIX into the “Test” Script. Added in the groups from the Child Domain Script. Checked to see if there were any missing Groups from the GOSUB Routines. We were now using WMI for Shortcuts and made the appropriate changes.
Changes in the Kixtart script: Server-Side Script execution- The Kix32.EXE file is copied to the client and asks the server for the Kixtart scripts. The Kixtart scripts for Company B were originally copied to the client workstation and executed.
Server/Terminal Server Check- If found, leave from the script. This used to be done from the NTLOGON.BAT file.
File Checks- Any Utilities are checked and if needed copied to the Workstation.
Printers- Copy the Default Printer settings to the User’s Personal Drive. We have been imaging and updating a number of our users and once the machine has been imaged or replaced, they lose their printer.
Outlook Once the user logs in the first time, they get MS-Outlook configured and setup.
Thanks everybody!
Kent [ 05. October 2002, 05:57: Message edited by: kdyer ]
|
|
Top
|
|
|
|
Moderator: Glenn Barnas, NTDOC, Arend_, Jochen, Radimus, Allen, ShaneEP, Ruud van Velsen, Mart
|
0 registered
and 837 anonymous users online.
|
|
|