Monty Carter

Use a wildcard in the element where you would normally define a static computername. **Without looking up the correct syntax, it would look something like this** <ComputerName>*</ComputerName> It is part of the Windows-Shell-Setup element, and goes in the specialize pass. http://technet.microsoft.com/en-us/library...460(WS.10).aspx

Because two of your apps are actually working, I would say that it isn't a problem with you overall strategy for installation, by itself. Without looking at the way each item works, it is impossible to say what your problem is. However, here are a few things that I would look into first: Try using a batch file to put all of your commands into, and call the batch file as a RunOnce or RunOnceEx. If all the commands work when typed manually, then you will only have to troubleshoot the 'autostarting' of this one command, rather than each one. Another benefit to a batch file, is that you can specify wait times, inbetween each command. If MSIExec is busy when the next command starts, the second app trying to install wont have access to msiexec, and wont finish properly. Add lines for logs to your command lines, if they are available for your installer. This will give you more insight into what is happening as each command line is called. Check spaces. Try changing the paths on the executables to not include spaces. Especially when using a command line to enter registry keys, quotation marks can become very confusing, as to whether they will end up in the key, or if they will be interpreted as string separators at the time the reg add command was run. Check the registry entries before you reboot. This way, you can see if any of the entries aren't going into the registry as you had inteded. One, in particular, I notice that there are three double quotes in the line to install java. I am sure that this won't be interpreted as you have intended. On this note, you could also add an additional command for each app to install. Make this the exact same as the line you want to use to install, however, add 'echo' in front and '>>commandlog.txt' behind each command. This way, you will get a text file listing all of the command that were run. If it is a syntax error that is preventing your apps from installing, this will be the easiest way to see them.

Gandraw, when you get PowerShell integrated into WinPE, will you let me know how it went? I really like PowerShell, but for WinPE, I have been mainly using a tool called WinBatch. I have been kind of interested in moving to PowerShell, because it is a more widespread tool, however, I thought there were .NET dependencies for PowerShell. When you get PowerShell working within WinPE, will you let me know if there was anything additional you had to include in your WinPE boot image, as prerequisites for PowerShell? I haven't really spent any time trying this myself, but I would be interested to know what is involved with integrating PowerShell into WinPE.

I haven't heard of a bootcd command, as part of the standard Windows deployment tools. I did notice, after googling, that it looks like it is a command line switch for Symantec's Ghost, to prepare captured Ghost images as a bootable CD. Could you elaborate a little bit, on exactly what you are trying to accomplish? I'm not sure exactly what you are trying to achieve... As for imagex, by itself, the only preparation that really needs to be done is sysprepping your Windows installation before capturing. Then, it is very straight forward... Capture your image, then, on your target computer(s), just apply the image, and let it boot up.

The first thing I found doesn't exactly require just a short one-line snippet of code, depending on how precise you want to be. This initial solution basically involves checking the version number on the executable for each application in Office. The problem is, that each application has a different version number indicating which service pack it is on. If you are just checking for the SP on the core apps (word, excel, powerpoint), the code could be fairly short. However, if you need to ensure that every app is on SP3, you'll have some work to do. Don't know what language you intend to use, so I can't give you any more detailed suggestions on the code, other than to say define variables for each exe version number for each SP. (For example, wordSP1=1.2.3, wordSP2=1.2.4, wordSP3=1.2.6) Then, check the version on the file and see which variable it matches. (If SPword==wordSP3, then give a gold star, or whatever it is you intend to do with this knowledge.) Oh, the link to the actual info you asked for... : How to check the version of Office 2003 products Forgot to mention... The potential problem with detecting just one application version may be this: Say on most machines Office Standard is installed. Six months go by, and you upgrade everybody to SP3. Then, a user requests Visio, or something. You install it. Now, does Visio have SP3 installed if you don't run the SP3 installer again? I actually don't know, but I would certainly research it before deploying changes across my organization.

I would say that, mainly, it's the natural progression of IT and software in general. A big problem with pre-Vista Windows was that administrator access was either all or nothing. UAC is more than just a feel-good measure to reassure enterprise users; it has real-world use cases. PowerShell is a much better scripting language, in my opinion, than VB and especially batch. Instead of going back and fixing everything in VB, they are pushing the new language. HTTP got SSL v1, then SSL v2, then SSL v3. Internet Explorer, however, maintains support for the older versions of SSL, because too much is already utilizing the older versions, and there would be a lot of unhappy campers. But, as maxXPsoft already mentioned, the simple solution is to disable it, and then as the last step in your PowerShell script, simply re-enable the default execution policy. (By the way... The PowerShell execution policies are very similar to the different zones in Internet Explorer (that is, Internet, Intranet, and Trusted zones)... Here is a decent explanation on the issue: Configuring PowerShell Execution Policies

Looks like you've got some reading to do... Here's a head start though. The options you would normally have to select during a regular, unautomated GUI install of Windows 7 can be automated through the use of what is called an unattend file. For Windows Vista and later (including Win 7), this file is Unattend.XML. Extensive customization of a Windows installation can be performed in an automated fashion using a complex Unattend.xml file. However, for starting out, you'll want just the basics. There is actually a good tutorial on it, included with the Windows Automated Installation Kit (WAIK). Part of the documentation that comes with WAIK is the Unattended Windows Setup Reference. In the beginning of this document, there is a page called "Settings to use for an unattended installation". This tutorial says that a key is required, but I am pretty sure that it is not required. You may want to read through the WAIK User's Guide, at least the beginning, first, so you kind of get a feel for everything that is going on. Anyway, once you get the gist the overall process, you should probably stick to that "Settings to use for an unattended installation" page at first. Once you get the hang of it, you can start to throw customizations in there. I actually wrote a blog about all the various tools used in Windows 7 deployments just a couple of weeks ago. You can check it out here: Windows 7 Deployment Technologies

You wont be able to capture a usable live image. Capturing an image requires access to every bit of information on the hard drive you are capturing (I lie... Technically you only need access to the entire volume, assuming you are using ImageX. Ghost does, in fact require access to the entire drive.). When Windows is running there are many files that are locked from reading and writing, because the functionality and stability of Windows is dependant upon these key files. Additionally, there are many changes that Windows makes to the hard drive right before shutting the system down... This is how, for example, Windows knows when you have unexpectedly shut down your computer due to power outage or otherwise (a message appears at boot time saying Windows wasn't shut down properly, and a check disk should be run) To capture an image of your hard drive, you will either need to use something like WinPE or BartPE. These minimal OS's are loaded from CD/DVD, USB flash, or network, and so no files are locked on the hard drive you are trying to image. If you download Windows Automated Installation Kit (WAIK), there is a great tutorial on how to build WinPE. (In the WinPE User's Guide). Just one more quick note... ImageX is not included, by default, in the base WinPE image included with WAIK. You'll need to add that to be able to utilize ImageX from within WinPE. (I can't remember if this is a "package" for WinPE, or if you have to add it separately, but the full instructions should be in the WinPE User's Guide included with WAIK. Let me know if this isn't the case...)

Were you able to solve your issues? If not, could you be more specific about what isn't working? Does it process any of the rules from your unattend file? If so, which rules aren't processed? Does the whole installation process fail? If so, when exactly? There is one thing I noticed, but I am assuming it was a copy/paste error. The unattend file that you posted doesn't close the opening <unattend> tag. I loaded the unattend file you attached into SIM, and it gave me an XML error because there wasn't a </unattend> tag at the end of the document. I guess you just missed the last line when copying?