cluberti

Unless you use AutoIt (and I'm not sure it would work, but it would be worth a try), no.

Here's how I'd do it - a ten step move server program: 1. Power down the system. 2. Install the Promise RAID controller into the existing server. 3. Power up the system, and install drivers for the Promise controller once Windows boots up. 4. Reboot, then ***make a full system backup, either via Ghost or some other backup software***. 5. Shut down your system. 6. Install the new drives to the Promise controller, and remove the old drive (do not reformat it until you're sure everything is running properly on the new array!). 7. Power up the system, and enter the Promise BIOS to create the RAID1 array. 8. Reboot. 9. Restore the Ghost (or whatever) backup to the new RAID1 array. 10. Reboot. If all goes well, you should have the server come back up on the new RAID1 array after step 10 without issue. I can't guarantee you this will work (because you can't run sysprep on a domain controller without losing all domain information, which would be bad!), but it should work if the drivers already exist for the RAID controller before you move the OS over to it.

Instead of JoinWorkstation, use the following: [identification] JoinDomain = YOURNETBIOSDOMAINNAMEHERE DoOldStyleDomainJoin = YES

Yeah, the Sempron 2500+ is a Palermo core part, so it should work . Try it with any other 754 ATHLON part, and it won't work. Only the Mobile Athlon and Sempron parts (on the Palermo core) will actually run without the error.

Yes, it's a 64bit chip (you were able to install an x64 version of Windows, which should be a dead giveaway ), and it is working in 64bit mode. Other than the advanced memory access capabilities and the larger register areas, there's not a whole lot of difference an end-user will notice between a 64bit chip and a 32bit chip (well, at least not yet). If it's a 64bit chip (I do believe it is), then yes, Windows XP Professional x64 would be a fine candidate for running on that system. Just be aware that there are some 32bit applications that will not run properly on a 64bit system, most notably 32bit antivirus programs.

When you enable "Maintenance Policy", you change the policy to "preference" mode. This means that the setting will take effect only if the client doesn't have something already set, and it will only apply ONCE. You should seriously consider disabling Maintenance Policy processing, and reconfigure all of your settings. Stay away from the Maintenance Policy processing unless absolutely necessary.

Have you cleared your DNS server's cache, and perhaps the client's DNS cache as well?

Are you logged in as the same user who is running the tasks, and are the tasks allowed to run interactively?

Have all of your drivers been extracted? If you can install devices by pointing them at the correct folder when using device manager, they should install properly during Windows setup. If you point the device at the folder and the driver doesn't install, you've got some work to do. It's the best way to test if you've gotten the drivers extracted properly or not for Windows installation - if it works by manually using the device manager to install the devices by pointing the update wizard at the proper folder, it'll work during Windows setup.

Well, you're missing about 80% of the command needed to make it work. Try the following: REG ADD %KEY%\020 /V 2 /D "\"%systemdrive%\v10.0.1.1000\SymantecAntivirus.msi\" REBOOT=ReallySuppress RUNLIVEUPDATE=0 ADDLOCAL=SAVMain,SAVUI,SAVHelp,EMailTools,OutlookSnapin,Pop3Smtp,QClient NETWORKTYPE=2 ENABLEAUTOPROTECT=1 /qn" /f

http://support.microsoft.com/default.aspx?...kb;en-us;555381 Google is your friend

Microsoft already has these on a share. Just call them and ask for it - if you bought your copy of Windows legally, you should be able to do this.

The problem with Installshield installers is that the setup.exe process is just a placeholder for the actual installation file, which is an .msi file. The setup.exe process checks for the existence of the necessary supporting file versions of the Windows Installer, installs the installscript package if the setup routine requires it, and then launches the actual .msi file. Unless you use the /SMS switch, setup.exe terminates at this point and hands off complete control of the installation to the Windows Installer engine - which is why "start /wait" doesn't work. What happens is that the setup.exe process completes and closes, and thus your script happily moves right along to the next line because "hey, setup.exe is done!". The /SMS switch forces setup.exe to stay loaded until the .msi installer returns an exit code (doesn't matter which, any exit code will do), and then it terminates. Make sense? I wish the powers that be, the ones who actually pack these installers up, would simply use the .msi file format instead of wrapping it in a setup.exe that no one should really need anyway. Oh well, why have a standard way of doing things when it can be done so many different (incompatible) ways? <sarcasm> Why use the built-in installer engine when we can write our own!!! </sarcasm>

Currently, Microsoft does not make these smaller hotfixes public, as a standalone hotfix still needs the package installer integrated to be able to be installed without being extracted (the WU/MU updates are extracted and installed from temporary folders on disk when downloaded).

Try not to use installation paths with spaces, and you never need to worry about what goes inside the quotes, and what goes outside the quotes, etc. Just a suggestion, from experience screwing things up .

The problem now, if PIDKEY didn't work (the supported method for Microsoft Installer applications created 100% compliant) is that Macromedia likely used InstallShield to create these .msi files, and have an installscript serial validation routine that you will not be able to get around, at least not without an AutoIt script (and even then, I don't know if it can be done for an attended install and be 100% reproducible ). edit: I just string'ed a Macromedia studio .msi for dreamweaver, and it was indeed built with InstallShield...

Any hotfix produced after SP2 (and some before SP2) listed on the WU/MU site are reduced in size, due to the fact that the package installer (the actual "brains" of the update) is now included in the OS itself. That means that the package installer (roughly 650KB) no longer needs to be included in each patch, and only code to be updated is actually packaged to the WU/MU site. While 650KB might not be a lot to those of us with broadband connections, it's quite a bit for someone on a dial-up or ISDN connection. And that's 650KB with every update that would otherwise have to be retrieved, which is horribly inefficient - as you've seen, it can be tens of megabytes that we can save a user from downloading when they need large amounts of patch data. There's no reason to include this in every patch if the update installer is the same for every patch, and the solution is to install permanently an (updateable) version of the package installer only once, and reuse that code for other updates.

Does the attribute "Microsoft LDAP Directory" exist in your LDAP?

Not sure if this will work or not, but on the command line used to install these .msi apps, use the PIDKEY=xxxx-xxxx-xxxx-xxxx switch to add the key. For example: msiexec /i path/to/installation/files/dreamweaver.msi PIDKEY=xxxx-xxxx-xxxx-xxxx The PIDKEY parameter can be used with most applications that require a product key, providing they were built to the .msi standard and don't require any fancy installshield scripting.

Do you host these domain servers, or are these hosted externally? If so, you should consider contacting your ISP and seeing what they have set for the TTL on domain records they cache.

kocoman, do you want to map your \Documents and Settings\user\desktop folder to another machine over the network, or do you want this directory to be a drive letter locally?

I did not write this, I got it from the Scripting Guys' site at Microsoft.com. It does work, so no need to reinvent the wheel : On Error Resume Next Const ADS_SCOPE_SUBTREE = 2 strPassword = "" Set objConnection = CreateObject("ADODB.Connection") Set objCommand = CreateObject("ADODB.Command") objConnection.Provider = "ADsDSOObject" objConnection.Open "Active Directory Provider" Set objCommand.ActiveConnection = objConnection objCommand.Properties("Page Size") = 1000 objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE objCommand.CommandText = _ "SELECT AdsPath FROM 'LDAP://dc=fabrikam,dc=com' WHERE objectCategory='user'" Set objRecordSet = objCommand.Execute objRecordSet.MoveFirst Do Until objRecordSet.EOF strPath = objRecordSet.Fields("AdsPath").Value Set strUser= GetObject(strPath) strUser.ChangePassword strPassword, strPassword If Err= 0 or Err = -2147023569 Then Wscript.Echo strUser.CN End If Err.Clear objRecordSet.MoveNext Loop

Network drivers can keep a machine from being able to power down too - make sure those are the latest version for your laptop.

Your setting is only for network drives (1). Try using a value of 4. Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer Value: ShowDriveLettersFirst Type: REG_DWORD Data: <see below> 1 - the drive letter is displayed first for remote drives only 2 - drive letters are not displayed 4 - the drive letter is displayed first for all drives, local and remote

It depends - for just office work, probably nothing (hey, people use the castrated Celeron too without too many issues for office work). However, if you're a gamer, or a "power user", or basically anyone who would be building their own PC ( ), you'll want at least 1MB of L2 cache.