Jump to content

tridgely

Member
  • Posts

    29
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

About tridgely

tridgely's Achievements

0

Reputation

  1. I used to use a DOS-based installation method, running winnt.exe, as clivebuckwheat has explained above. This method has some limitations to it that caused me to switch over to Bart's PE for winnt32. Using winnt.exe in DOS, your filenames must match an 8.3 filename restriction, which many of my installers in $OEM$ did not. Because of this, I used to 7zip them all up and unpack them after the install, but it was tedious to maintain. Also, you have a restriction on the amount of data that you can copy over. I believe it's 2 gigs, but that could be wrong. I've been very happy since I switched to Bart's PE. The learning curve was fairly steep, so I was up and running pretty quick. @clivebuckwheat, if you have a $OEM$ distribution folder, basically used to copy extra files over during setup, it would normally need to be placed inside the i386 folder for a network-based installation via winnt.exe. However, if you make an entry in your unattend answer file, you can specify the location of the $OEM$ folder. By placing a line with: OEMFilesPath="..\$OEM$" In your unattend file, then you can keep $OEM$ parallel to (alongside) the i386 folder. After this is all said and done, will create a batch file in DOS to map the drive via net use, and then run winnt.exe from the i386 folder, with the switches that you want. I'm not 100% sure what you're having trouble with, but I'm more than happy to explain further if it helps you.
  2. What do you mean by a "normal" boot CD? Are you loading DOS, or some variant (e.g. FreeDOS)? If so, winnt32.exe won't run, but winnt.exe will, and you can use the same basic idea. You've got the concept...load some OS from the CD, connect to the network, start the Windows install via winnt.exe or winnt32.exe (depending on your OS), reboot. Easy! On a side note, if you specify "..\$OEM$" for the OEMFilesPath in your unattend file, you do not have to embed $OEM$ inside I386; you can keep it parallel. This is useful if you decide to use junctions to create network installation sources on-the-fly (I made a PHP app for our technicians to customize the $OEM$ folder for their particular install needs).
  3. I set up the source with the $OEM$ production folders on a network share, then start the computer with Bart's PE, map a network drive to the share, and start winnt32.exe from there. Try searching the forums for winnt32 or winnt32.exe; there's a bunch of info.
  4. New XP Update: Security Update for Windows XP (KB914798) Brief Description A security issue has been identified in Windows-based systems that could allow an attacker to compromise your system and gain control over it. MS Download
  5. The Netgear FA120 USB network card has never seemed to be included in the lan dp. Available from: ftp://downloads.netgear.com/files/netgear1/FA120.zip
  6. If you apply that during T-12 (from cmdlines.txt), it will be applied to all users, which is probably what you want. Make a .reg file with that tweak in it. Then make a .cmd file that runs regedit silently to apply the tweak. Then make an entry in cmdlines.txt to run the .cmd script.
  7. Use the following reg key: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel] "{20D04FE0-3AEA-1069-A2D8-08002B30309D}"=dword:00000000 "{450D8FBA-AD25-11D0-98A8-0800361B1103}"=dword:00000000 "{208D2C60-3AEA-1069-A2D7-08002B30309D}"=dword:00000000 "{871C5380-42A0-1069-A2EA-08002B30309D}"=dword:00000000
  8. See, you're missing the point. The method you just described is dependent on the NIC driver working--in a varied environment, it's not really possible for that to happen. I already got Unattended working in a similar way, but it fails pretty horribly if the NIC isn't detected. The way I've reworked it, all the necessary files will get copied over during text-mode setup, so they won't be dependent on a NIC working post-install. Thanks for the suggestions--I've already used AutoIT to make a selection system similar to kTool (but with treed checkboxes) that will configure user accounts and set up Outlook automatically.
  9. I'm just a student employee though, so I have basically no say in the matter of AD. Besides, I'm actually pretty happy with how the modified Unattended has turned out. Because of the 8.3 filename limitation, I wound up changing it more (testing it out this week) to 7zip all the packages into their own zips and extracting them after the network copy to preserve non-8.3 limitations. Just more batch file making, etc...nothing too bad.
  10. You do not need any Microsoft add-ons to install XP over a network. All you need is the XP install source (basically, copy the CD to a folder on your hard drive). There are plenty of ways to accomplish what you want to do for free! A Sourceforge project called Unattended does what you want; more info is available from their web site: Unattended. If you're running a domain with Active Directory, you can also use Remote Installation Services (RIS), but it doesn't sound like you are, so I'd stick with Unattended. The idea behind Unattended is just to map the network share you're creating to a drive letter in DOS/Linux and run winnt.exe to kick off the Windows install. So, alternatively, you could just build a DOS or Linux bootdisk to map the share and run WINNT.EXE with the necessary parameters. More info can be found by reading Microsoft documentation. This might be better, because Unattended can be a bit intimidating at first; I nearly scrapped it when I was first getting used to it, because I preferred the simplicity of just booting into DOS, mapping the drive, and running winnt.exe. I'm still using Unattended, although I've gone through and customized what I want.
  11. Hey all- I wanted to see how you guys who install XP over a network do it. I started looking into RIS, but our university's domain (I work for the IT group) doesn't use AD, so that got scrapped pretty quickly. Switched to Unattended and got that working, but I've been finding it less-than-satisfactory lately. Unattended installs Windows, and then maps a network drive to the install share to install all the apps and do all the post-install configs. The problem is that we support a wide range of computers, and the NIC driver is not always detected (even with BTS DPs). So I decided one day that I wanted to rework the way Unattended works to avoid the problem. The simplest solution would be to put all the apps and such into the $OEM$ production folder, but we have a large set of site-licensed software (around 25 gigs worth), so that's out the window, because the server could not handle copying 26 gigs of data for each XP install. The problem is such: I want ONLY the necessary applications put into the production folders, so that Windows will copy them over before the install starts (thus cutting the dependence on the NIC driver working), but without copying any extraneous apps. I'm currently accomplishing this by customizing Unattended somewhat. I set up Apache on the Unattended server, and programmed a basic PHP interface. A person signs on, gives the install a "session name" and selects the applications he wants to install. The server then creates a new XP folder and uses junctions and hard links (junctions and hard links are like symlinks in Linux) to "copy" the XP install files to the new folder, and then I use more junctions to "copy" the apps into the production folders. So, basically, there's a new XP folder on the computer named after the provided session name, but it's all symlinks, instead of being actual files, so it takes up almost no space on the drive. The person then goes in through the Unattended boot and chooses to install XP from the folder. Text-mode setup copies the production folders over, and XP and all apps install from the hard drive after that. I then just rigged a cleanup script to run every night and cleanup all the sessions. Junctions can be created with Sysinternals' Junction tool: web site Example script to create the symlinked dir (called "TestSP2" in the script) from a regular windows install dir (called "XPSP2")...I subsituted %1 for TestSP2 in the real script to make it callable w/ parameters. :: CreateDir.cmd mkdir D:\install\os\TestSP2 mkdir D:\install\os\TestSP2\i386 mkdir D:\install\os\TestSP2\i386\$OEM$ mkdir D:\install\os\TestSP2\i386\$OEM$\$1 mkdir D:\install\os\TestSP2\i386\$OEM$\$1\Install junction D:\install\os\TestSP2\i386\$OEM$\$1\Tools D:\install\packages\Tools junction D:\install\os\TestSP2\i386\$OEM$\$1\D D:\install\os\XPSP2\i386\$OEM$\$1\D junction D:\install\os\TestSP2\i386\$OEM$\$$ D:\install\os\XPSP2\i386\$OEM$\$$ junction D:\install\os\TestSP2\i386\ASMS D:\install\os\XPSP2\i386\ASMS junction D:\install\os\TestSP2\i386\COMPDATA D:\install\os\XPSP2\i386\COMPDATA junction D:\install\os\TestSP2\i386\DRW D:\install\os\XPSP2\i386\DRW junction D:\install\os\TestSP2\i386\LANG D:\install\os\XPSP2\i386\LANG junction D:\install\os\TestSP2\i386\SYSTEM32 D:\install\os\XPSP2\i386\SYSTEM32 junction D:\install\os\TestSP2\i386\WIN9XMIG D:\install\os\XPSP2\i386\WIN9XMIG junction D:\install\os\TestSP2\i386\WIN9XUPG D:\install\os\XPSP2\i386\WIN9XUPG junction D:\install\os\TestSP2\i386\WINNTUPG D:\install\os\XPSP2\i386\WINNTUPG junction D:\install\os\TestSP2\cmpnents D:\install\os\XPSP2\cmpnents junction D:\install\os\TestSP2\docs D:\install\os\XPSP2\docs junction D:\install\os\TestSP2\support D:\install\os\XPSP2\support junction D:\install\os\TestSP2\valueadd D:\install\os\XPSP2\valueadd fsutil hardlink create D:\install\os\TestSP2\i386\$OEM$\$1\Install\start.cmd D:\install\packages\start\start.cmd The software packages are all located (for me) in D:\install\packages, so I basically have a batch file like so: (LinkPackage.cmd) :: LinkPackage.cmd junction D:\install\os\TestSP2\i386\$OEM$\$1\Install\%1 D:\install\packages\%1 And then I need to hard link the files individually from XPSP2\i386 to TestSP2\i386. We cannot just junction the i386 folders together because we need to put a "custom" $OEM$ in TestSP2\i386, and if we just junctioned them, when you then made $OEM$ in TestSP2\i386, it would also be created in XPSP2\i386, and that's wrong. So I made an AutoIt script to pull a directory list and run "fsutil hardlink create" for each one. This duplicates the contents of the i386 folder, but leaves me free to modify the TestSP2 one all I want. It's not as convoluted as it sounds, but I figured I'd ask and see if anybody has any suggestions/ideas for improvement. Maybe somebody can improve on it...I think this way works MUCH better than the original Unattended for widespread use (I've had too many Unattended installs crash because the NIC driver couldn't be found). LMK what you think!
  12. I don't have a key code; I'm just installing the trial version. I don't see how adding the /KC switch is going to change anything, and I'm already using /VERYSILENT. Trial Download Link It does install near-silently when I'm using /VERYSILENT /SP- (i.e. it doesn't prompt me for most of the install tasks), but it prompts to check if I want to update the defs before install, and then it brings up a browser window. I think that it's because of new functionality Webroot has created for the newer versions.
  13. SS has been updated to 4.0.4.430 I'm trying to install it (/VERYSILENT /SP-) and it brings up a prompt asking if I'd want to download and install new updates. It then opens a browser window. I went through with innounp 0.16 and it looks like the install script generated is incomplete. It won't recompile cleanly at all. I went through most of the error messages and removed parts from the script to make it work, but now it errors on compilation here (from install_script.iss): Source: "{app}\WRSSSDK.exe"; DestDir: "{app}"; AfterInstall: "RunServiceInstall"; MinVersion: 4.1.1998,4.0.1381; Flags: uninsneveruninstall restartreplace ignoreversion It doesn't like the AfterInstall part...RunServiceInstall is not defined. At this point, I'd have to rewrite that bit in order to get it working. Anybody know how I could better unpack the installer, so it's not losing these pieces? I don't want to resort to AutoIT if I don't have to.
  14. Couldn't honestly say. I've never seen/used XPCREATE -- still on the waiting list. I just use RyanVM's latest pack and then manually integrate the remaining updates.
  15. Here's how I got this to work: Manually integrate RyanVM Don't use nLite at all (I couldn't get it to work, anyway, and it was quicker to do the things I needed manually than to mess around with it) Use BTS DPs with Method 1 (Method 2 was causing the Wizard to appear, Method 1 does not appear to) Change production folders how I want, add modified system files, etc.
×
×
  • Create New...