GreenMachine
Content Type
Profiles
Forums
Events
Posts posted by GreenMachine
-
-
I noticed the risk because the file advpack.dll was the wrong version. It was listed in the setuperr.log (or .txt) file, and that started me looking. Even then, it did not seem to harm anything. Still, better safe than unsure.
I had not really given a thought to the fact that they were run the second time out of order, in svcpack.inf. Oooops. I think I will be renaming them so that alphabetical and chronological order are the same.
I do not care about automatically renaming them, because I like to scrutinize the hotfix before deciding to use it, and the renaming is not a big issue - I've already got my hands in there. The Q12345~1.exe method works fine I think, but I never quite swallowed how poorly windows went from 8.3 to long files, so I (almost) exclusivly use 8.3 from the get-go.
If I'd've known about %~dp0 I would have used it, but I am probably better at assembler than DOS batch commands.
You said you had a good look at my code. Did you notice, like I did, that is becomes much clearer between the first and second pint?
Once you get the kinks out of your new script, please do share (again)
0 -
The uninstall switch when installing the hotfix avoids the need for this (in ALMOST all hotfixes). (No offense, Doug...)
0 -
RoyalBox!
My base version of the RHSM (Royal Hotfix Scripting Method) is your original post, plus changes added by others to include HotFix Type 2. I ran into issues with all KB hotfixes running first, and then all Q hotfixes, and then the same thing with type 2 hotfixes. They were not in chronological order, and I did see some incorrect overwrites. I thought about nameing them all Q######.exe, but I remember reading on MS's site that the hotfix number itself could not insure correct component versioning. XCOPY was the best I could come up with, though it would be ideal if it could do a version check instead of a date check. I extract them each to a seperate directory (Q######) so that I can look at them afterwards, should the need arise.
The PREPDIR thing, as I am sure you figured out, is just to alow runing the script from anywhere, as the type 2 hotfixes, unlike the type 1, require a complete extraction path. This enables me to get them into a subdirectory of my working directory.
As regards the type 2 hotfixes working, it seems they do, but in any event ALL these hotfixes are run during setup, so the changes get there one way or another, and the updated files will be present on the CD, so I think it's OK. I have the most faith in the hotfix itself, and that is why I will never install without them, as suggested in another thread. I only do 4 this way: KB814078, Q327405, Q330994, Q822925, and have not had any problems (that I noticed ...) Bottom line is, I don't think it hurts.
The other system updates: .Net, MDAC, JavaVM and combined WMP/MM, I consider special items, and do not attempt to slipstream them. I run those 4 items, plus the WMP update, from the batch file called in CMDLINES.TXT.
On a side note, I was bothered that the Q817287 hotfix did not seem to accept the uninstall switch, and it would leave behind a C:\Windows\$NTUninstall.....$ folder. It was the only one I had, so the imperfection bugged me... I extracted the hotfix, and it seemed to me that the type 2 hotfix setup was just a wrapper for a type 1 hotfix. The setup basicaly stopped a service, called the type 1 fix, and restarted the service. I just use the extracted type 1 fix, and it works fine as such, as the service in question was never started anyway. No entry in the uninstall list, no hidden uninstall directory.
0 -
Does this method prevent the error message in the setuperr.txt (or whatever it is called)? I did as many others, and just copied a version posted here into the I386 directory. Works fine, yet is listed as a problem in the error log, and causes a red flaged event in the event log. Does hacking the checksum overcome this problem as well, or does it just prevent setup from crashing?
0 -
I will certainly take the exrta 10 minutes to start over: copy the files from CD, slipstream SP2, ... and wait for the next wave of hotfixes.
0 -
I agree 100% with the snoozer, but then if you cannot do it with a batch file and regedit, it's not for me. If I were to use another method, I would simply log on to a new installation, make all my desired changes, save the user's registry hive file (NTUSER.DAT), and copy it to the Default User's profile during setup.
0 -
Do you think that we should be using the "start" command in the generated .cmd files in that case? i.e.
start /wait "HFTYPE1\Q282010.exe" /q /x:EXTRACT\Q282010
instead of
HFTYPE1\Q282010.exe /q /x:EXTRACT\Q282010
0 -
For reasons stated HERE, my vote is for #2, the Standard and Documented Microsoft way, regardless of whether this is done manually, or in a batch/script routine.
0 -
It is true that removing the actual hotfixes saves about 40 MBs, but that is off no matter to me: my windows installations are windows only installations. I need alot more that 40 MBs to install all the additional programs I will install, but I like to keep things modular - thus simple and easy to debug. Without really knowing what each of the hotfix setups does, I would not remove them. Do they do the exact same thing on all computers? If there is a single "IF" satement in the code... I will never try to understand that code so in depth: I will never remove them. At best, it will introduce instability questions. At worst, I smell a maintenance and weekly (wednesday) updating nightmare. My interest in slipstreaming the hotfixes is added stability. This is, to me, a step in the other direction. Windows update must also work correctly, or, in the words of another member, what's the point? The extra 15 or so minutes does not concern me, either: I am not there to see this, nor the fancy .inf / RunOnceEX installations.
Now that the Project's Father is back on line, perhaps we should baptise this the Royal Hotfix Sipstreaming Method?
God Bless the Queen.
0 -
The SET command takes care of the variables - adds, deletes, modifies and lists 'em. You can do it from the command prompt or in a batch file, there is not really much to it. Type set /? for usage ...
SET VARNAME=VARVALUE ; You have the variable name VARNAME assigned the value VARVALUE
SET VARNAME= ; Variable VARNAME is gone
SET X=%VARNAME% ; X now equals VARVALUE
0 -
For what it's worth, I PMd you my copy of your work. I'm done, so the balls back in your court.
0 -
Oh, man, you took all the mystic out of the zz###s. I was just starting to enjoy it ...
0 -
Hey, waita minute, does't anyone read my posts?
in response to your post in THIS THREAD. You certainly have a right to your pride, and I understand that it would have been better in that thread. I would have liked to have seen it from the begining as well. If it is of any consolation, I think what happened is that during the MSFN down time of a couple of days earlier this month, people lost their train of thought. So that it does not go unsaid: Jolly good show, RoyalBox, and thank you for sharing your work with us! And thank you for being the cause of these lively discussions! (What good is an ego, if you can't show it once in a while?)Thanks, Royalbox. Credit where credit's due0 -
I think you are correct: the Default User\NTUSER.DAT hive is already in use, so there is not much sense in loading / unloading it. Snooz seems to concure, as he said he has tried them both, and they both work. I have not tried yet, so I cannot speak from experience. Default User\NTUSER.DAT contains the New User Template, and some things in there will only be used to initialize a new profile. You make the changes there, and when you next create a new user, the changes will be visible. My experience leads me to believe that many explorer settings are saved to the registry just before shutdown / logoff, such as default folder view options, taskbar settings, and who knows what else, thus will always overwrite your changes. For this reason you must load the default hive, make the changes there, and use it as a template. You can get away with making changes during the pre-gui-reboot because the shell (explorer) has not yet been loaded, thus will not save it's settings on exit.
0 -
I'd like a look.
7z, eh. Sounds like a pretty efficient zipper. Do they have an SFX option?
0 -
If you do not have the rm.exe, a UNIX like remove utility, (didn't come with my windows) use the windows built-in command rmdir (remove directory, rd for short) instead. Type rmdir /? at the command prompt for usage.
0 -
Try "%PROFILESDIR%\Default User" instead of (nonexistant) %DEFAULTUSERSPROFILE%.
I get the feeling I already said that ...
0 -
SQL can be installed using the Unattended InstallShield Method, described here somewhere (in the guide, perhaps?). You basically run setup with a switch, input all the data, and finish. Instead of creating the install, a silent install file is created, which you will now need to pass to setup when calling it. The guide is more informative than my 3 sentences ... I'm not sure about VS, but a quick try will tell you for about 1 minutes work. Don't know about illustrator either. If you get it working for VS please let me know. I've had a lot of luck with google searching for APPNAME and "Unattended install".
0 -
Thanks, Royalbox. Credit where credit's due: I'd been meaning to try that slipstream for a while, but could not make the first step. Following is my modified version of WebMedics version. I simplified certain parts (only do fix type 1 and 2, no MDAC), and made others more complicated (each file extracted to it's own directory, XCOPY instead of COPY for selective date based copies), and changed the directory structure (after about 5 beers, I can no longer keep track of single digit variables / directories). For what it is worth, here it is. You need the fixes in either directory HFTYPE1 or HFTYPE2, the expanded SP1.CAB in directory SP1CAB, and the files COMPRESS.EXE, CABARC.EXE, HOTKILL.INI in the root of your chosen directory. It is path indepedant, and works (for me ...) with long file names. But I guess I do not need to walk you through it: the code is fairly readable.
@echo off
setlocal enableextensions
REM - Shamelessly copied from others posted work ...
REM ---------- Initialization ----------
ECHO Find out where we are ...
SET PREPDIR=
FOR /F "delims=" %%i IN ('cd') DO SET PREPDIR=%%i
ECHO We are at %PREPDIR%.
REM ---------- CleanUp & Preparation ----------
ECHO Cleaning up first.
if exist WORKDIR RMDIR "WORKDIR" /S /Q > NUL
if exist SAVEDIR RMDIR "SAVEDIR" /S /Q > NUL
if exist EXTRACT RMDIR "EXTRACT" /S /Q > NUL
MKDIR WORKDIR
MKDIR SAVEDIR
MKDIR SAVEDIR\SVCPACK
MKDIR EXTRACT
if exist HFTYPE1.cmd del /q HFTYPE1.cmd > NUL
if exist HFTYPE2.cmd del /q HFTYPE2.cmd > NUL
REM ---------- Extract Type 1 HotFixes ----------
ECHO Extracting Type 1 Fixes ...
for /f "usebackq delims==" %%i in (`dir /b HFTYPE1\*.exe`) do (
echo HFTYPE1\%%~ni.exe /q /x:EXTRACT\%%~ni >> HFTYPE1.cmd
echo xcopy /d /h /y /s EXTRACT\%%~ni\*.* WORKDIR >> HFTYPE1.cmd
echo if exist EXTRACT\%%~ni\SP2 xcopy /d /h /y /s EXTRACT\%%~ni\SP2\*.* WORKDIR >> HFTYPE1.CMD
)
if exist HFTYPE1.cmd call HFTYPE1.cmd
REM ---------- Extract Type 2 HotFixes ----------
ECHO Extracting Type 2 Fixes ...
for /f "usebackq delims==" %%i in (`dir /b HFTYPE2\*.exe`) do (
echo HFTYPE2\%%~ni.exe /Q /T:%PREPDIR%\EXTRACT\%%~ni /C >> HFTYPE2.cmd
echo xcopy /d /h /y /s EXTRACT\%%~ni\*.* WORKDIR >> HFTYPE2.cmd
echo if exist EXTRACT\%%~ni\SP2 xcopy /d /h /y /s EXTRACT\%%~ni\SP2\*.* WORKDIR >> HFTYPE2.CMD
)
if exist HFTYPE2.cmd call HFTYPE2.cmd
if not exist WORKDIR\* goto _end
REM ---------- Save the files to be copied to the distribution ----------
ECHO Copy Fixes to SVCPACK
copy /y HFTYPE1\*.exe SAVEDIR\SVCPACK > NUL
copy /y HFTYPE2\*.exe SAVEDIR\SVCPACK > NUL
REM ---------- Save off the .cat files.
ECHO Move the .cat Files.
for %%i in (WORKDIR\*.cat WORKDIR\UPDATE\*.cat) do move /y %%i SAVEDIR\SVCPACK
REM ---------- Clean up some ----------
if exist WORKDIR\SYMBOLS RMDIR "WORKDIR\SYMBOLS" /S /Q > NUL
if exist WORKDIR\UPDATE RMDIR "WORKDIR\UPDATE" /S /Q > NUL
if exist WORKDIR\COMMON RMDIR "WORKDIR\COMMON" /S /Q > NUL
if exist WORKDIR\SP1 RMDIR "WORKDIR\SP1" /S /Q > NUL
if exist WORKDIR\SP2 RMDIR "WORKDIR\SP2" /S /Q > NUL
for /f %%i in (hotkill.ini) do del /f /q /s WORKDIR\%%i > NUL
REM ---------- Update any files that are also in the SP1.CAB ----------
ECHO Merge the 2 packs.
xcopy /d /h /u /y WORKDIR\*.* SP1CAB
ECHO Make SP1.cab
cabarc.exe N SAVEDIR\sp1.cab SP1CAB\*.*
REM ---------- Compress to MS format ----------
ECHO Compress all the files
compress.exe -d -r -zx21 WORKDIR\* SAVEDIR
REM ---------- Generate the .inf file -----------
ECHO Create the .inf file.
echo [Version] > svcpack.inf
echo Signature="$Windows NT$" >> svcpack.inf
echo MajorVersion=5 >> svcpack.inf
echo MinorVersion=1 >> svcpack.inf
echo BuildNumber=2600 >> svcpack.inf
echo. >> svcpack.inf
echo [SetupData] >> svcpack.inf
echo CatalogSubDir="\i386\svcpack" >> svcpack.inf
echo. >> svcpack.inf
echo [SetupHotfixesToRun] >> svcpack.inf
for /f "usebackq delims==" %%i in (`dir /b HFTYPE1\*.exe`) do echo %%~ni.exe /n /q /u /z >> svcpack.inf
for /f "usebackq delims==" %%i in (`dir /b HFTYPE2\*.exe`) do echo %%~ni.exe /Q:A /R:N >> svcpack.inf
echo. >> svcpack.inf
echo [ProductCatalogsToInstall] >> svcpack.inf
for /f "usebackq delims==" %%i in (`dir /b SAVEDIR\SVCPACK\*.cat`) do echo %%~ni.cat >> svcpack.inf
REM ---------- compress svcpack.inf ----------
ECHO Compress the .inf File.
compress.exe -d -r -zx21 svcpack.inf SAVEDIR
REM ---------- copy new system files to output folder ----------
ECHO Copy any Additional Files.
if exist SYS\*.* xcopy /y SYS\*.* SAVEDIR
:_end(I hate those long posts with too much code to read ... sorry!)
0 -
Not to be nit-pickin' ... From what I've tried and read, DefaultUsersProfile never exists. Certain variables are available during setup, certain other during run-time. You can type the SET command without parameters or switches to see the current list of environment variables. If you are curious, you could add something like
PAUSE
SET
PAUSE
to one of your setup batch files, and you can see what is there to use.
Concerning Jeffr's problem, as WebMedic says, be sure the directory exists. I prefer to use XCOPY, with the full directory structure. Eliminates these kind of problems, avoids checking to see if directories exist, and is generally a much better command than COPY (date compare, only copy existing files, etc). Also, should you running this in the pre-gui reboot stage of setup, USERNAME will not exist.
Strange: I went through a lot of research to figure out how to keep the Media Player link from being added to the quick launch bar...
0 -
Good eye, Kenneth, for the missing [COMMANDS] statement: I bet that is it.
I would have said that order is important on the NET LOCALGROUP command, but in testing it does not seem to matter.
User.cmd lives, and remains, on the CD only, directly in the $OEM$ directory. cmdlines.txt lives there as well, and is "run" automatically if it exists. It may depend on OEMPreInstall, can't remember right now. That will be in the ref.chm file that comes with setupmgr.exe of the deployment kit. (It is in fact parsed, and the commands passed to the command interpreter...)
0 -
Should readStatement 1:XCOPY /E /C /Y /Q /H ".\Profiles\*.*" "%ProfilesDir%\"
Statement 1:XCOPY ".\Profiles\*.*" "%ProfilesDir%\" /E /C /Y /Q /H
Statement 2: For some reason either %PROFILESDIR% is evaluating to NULL, and the drive E is used, as there is no drive letter in the path. Or perhaps you previously defined PROILESDIR to be "E:\"? If not, I would think that E: is the CD drive letter, which would explain the "Unable to create directory - E:\Default User" error - cannot create a directory on the CD. If you are unsure of the PROFILESDIR value, you can add this to your batch file:
ECHO PROFILESDIR is %PROFILESDIR%
and it will show you on the screen where it thinks the profiles are to be kept.
PROFILESDIR is undefined after the cmdlines.txt portion of setup, and could cause both your problems if it is undefined. If you get the first statement working, you do not need the second statement: just put your files in the Profiles directory, with the proper directory structure.
I have never found a way to prevent Windows from re-defining the Start Menu Sort Order whenever MenuItems are re-arranged, or new programs are added, but I have not looked too far as my solution works fine. (I never re-arrange by hand, and it is VERY rare that I add a new program.)
0 -
start /wait %systemdrive%\Updates\q282010.exe /Q /U /Z
Can't remember if you need quotes when using envronement variables... Perhaps
start /wait "%systemdrive%\Updates\q282010.exe" /Q /U /Z
If you put a "PAUSE" at the end, you will be able to see any error messages written to the screen.
0 -
I see you have a pause at the end of the batch file. Before you press any key, see if there is an error message after the NET commands. You should have either an error, or a "Command Successful" type message. Do tell!
0
PROFILESDIR and other variables
in Unattended Windows 2000/XP/2003
Posted
I believe I mentioned in one or two threads that the variable PROFILESDIR was available for use, and I would like to tell those whom I may have mis-lea, that I myself was mis-led. You are able to set the location of the users profiles with this entry in WINNT.SIF, but the variable itself is not availabe.
I interupted setup at the cdlines.txt point, and discovered this list of available variables:
Barring any typos, this list should be correct. The actual values of the variable, of course, may vary.