cluberti

Worth it? At 5.9, probably not. And the RAID really isn't going to give you much benefit unless you're copying larger numbers of files to or from the drive frequently, and even then the benefits may be marginal over a single drive. Unless this is a volume that's going to store a large number of multimedia files or large archives (like ISOs, perhaps) and will get frequently accessed, your best bet with desktop RAID is redundancy, not speed (RAID1 vs RAID0 or RAID10).

Both accounts banned (other post) - violation of homework rules and opening multiple accounts to do so. Come back when you've grown up a bit.

Both accounts banned (other post) - violation of homework rules and opening multiple accounts to do so. Come back when you've grown up a bit.

It isn't, but tools like MDT allow you to have drivers, updates, software, and images all separate and install similar to how XP setup worked (install Windows down, then integrate any drivers and updates into the image during WinPE setup, then reboot and install software - reimage to a WIM if the task sequence is configured to capture after deploy). It's worth looking into, although if you've got something working properly I wouldn't switch unless there's something different or a better process than what you currently use.

The .msp file goes into the Updates folder, along with any patches you want office to install automatically. If you only have one answer .msp file in the \updates folder on the office installation media, it will get used automatically by setup.exe.

It might be worth installing and capturing with imagex (or use MDT to automate the build and capture) and see if that changes things. If you're getting a stop 0x24 in ntfs.sys right after sysprep, and you know the drive is kosher, then most likely the disk driver or a disk filter driver (antivirus, maybe?) could be getting corrupted during the imaging process - any crash in a disk filter driver or disk controller driver is going to show as "ntfs.sys" during a BSOD. Considering you can drop a non-sysprep'ed image down without issue, I would say most likely your imaging is suspect, and finding a viable workaround (imagex, WDS, MDT, etc) might be a better choice long-term.

We've had this discussion before, here. I would suggest running "winsat disk -v" on both machines and compare output after reading the entirety of that thread and you'll probably find out why they're scoring the same. Benchmarking tools like HDTach are great for measuring synthetic benchmarks, whereas the winsat tests really beat on the drives in very specific ways, and would technically be more accurate in "real world" Windows performance on the device.

Indeed - unlike Vista/Win7, each XP CD is specific to the version on it, and you can't use an OEM CD to install retail keys, and vice-versa. This is expected. This branding changes over the years, and it would seem there should be an OEM name on it, but it's not *required*. It's a bit odd, but it's not impossible to find an OEM license / COA without the OEM name on it if it's a refurb or overstocked machine that HP unloaded. Unfortunately, MS doesn't provide OEM CDs directly - calling MS for an HP OEM CD isn't going to get you anywhere (especially considering it's XP, which is out of mainstream support). You are probably going to have to contact HP ultimately, especially if this was a recovery-partition-only machine.

Logon scripts don't run for published apps, because the hooks for logon scripts are actually in the shell (if they don't fire, which they won't when explorer.exe isn't launched, you won't get a logon script for the user). One thing you can try is to run a "pre-flight" script which calls "runonce /alternateshellstartup" and then starts the published app. If not, you're stuck running a script to launch your "logon script" and then the app, unfortunately. Windows just wasn't designed not to have the shell running.

There's a pretty good high-level overview in the wikipedia page for Vista.

There was a bug filed for this particular USB crash on Vista RTM and SP1, and it was fixed in Windows 7 (I know because I tested the test patch for this during beta). However, Vista SP2 doesn't add an updated binary for this file, so this may not have actually been fixed on Vista. Normally !analyze -v in these cases isn't sufficient, but in this case it is: 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_POWER_STATE_FAILURE (9f) A driver is causing an inconsistent power state. Arguments: Arg1: 00000003, A device object has been blocking an Irp for too long a time Arg2: 86970028, Physical Device Object of the stack Arg3: 86c1f028, Functional Device Object of the stack Arg4: 860e8008, The blocked IRP Debugging Details: ------------------ DRVPOWERSTATE_SUBCODE: 3 IRP_ADDRESS: 860e8008 DEVICE_OBJECT: 86970028 DRIVER_OBJECT: 866ba9a0 IMAGE_NAME: usbuhci.sys DEBUG_FLR_IMAGE_TIMESTAMP: 47919050 MODULE_NAME: usbuhci FAULTING_MODULE: 87ff2000 usbuhci CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x9F PROCESS_NAME: System CURRENT_IRQL: 2 LAST_CONTROL_TRANSFER: from 8206d3ab to 82109b0d STACK_TEXT: 82131acc 8206d3ab 0000009f 00000003 86970028 nt!KeBugCheckEx+0x1e 82131b28 8206cfc8 82131b94 82131c50 8214a401 nt!PopCheckIrpWatchdog+0x1ad 82131b68 820e62eb 8214a4e0 00000000 484a0a50 nt!PopCheckForIdleness+0x343 82131c88 820e5eab 82131cd0 8c6fab02 82131cd8 nt!KiTimerListExpire+0x367 82131ce8 820e6615 00000000 00000000 003f6dff nt!KiTimerExpiration+0x22a 82131d50 820e487d 00000000 0000000e 00000000 nt!KiRetireDpcList+0xba 82131d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x49 STACK_COMMAND: kb // You are running Vista SP2...: 0: kd> lmvm nt start end module name 8203c000 823f5000 nt Loaded symbol image file: ntkrpamp.exe Image path: ntkrpamp.exe Image name: ntkrpamp.exe Timestamp: Tue Aug 04 05:26:11 2009 (4A77FEB3) CheckSum: 00370777 ImageSize: 003B9000 File version: 6.0.6002.18082 Product version: 6.0.6002.18082 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 1.0 App File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: ntkrpamp.exe OriginalFilename: ntkrpamp.exe ProductVersion: 6.0.6002.18082 FileVersion: 6.0.6002.18082 (vistasp2_gdr.090803-2339) FileDescription: NT Kernel & System LegalCopyright: © Microsoft Corporation. All rights reserved. //...but your usb device driver is from Vista SP1!: 0: kd> lmvm usbuhci start end module name 87ff2000 87ffd000 usbuhci Loaded symbol image file: usbuhci.sys Image path: \SystemRoot\system32\DRIVERS\usbuhci.sys Image name: usbuhci.sys Timestamp: Sat Jan 19 00:53:20 2008 (47919050) CheckSum: 0000AF6F ImageSize: 0000B000 File version: 6.0.6001.18000 Product version: 6.0.6001.18000 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: USBUHCI.sys OriginalFilename: USBUHCI.sys ProductVersion: 6.0.6001.18000 FileVersion: 6.0.6001.18000 (longhorn_rtm.080118-1840) FileDescription: UHCI USB Miniport Driver LegalCopyright: © Microsoft Corporation. All rights reserved. I'm not sure how this is possible, because there are a bunch of drivers SP2 doesn't update, but I can reproduce this and can confirm most of the usb* binaries don't get updated by SP2. I would consider contacting Microsoft on this (you should be able to open a free case, considering this is indeed a known bug) and see if there's something specific that can be done to get this fixed on Vista SP2. I know for certain it was fixed for Win7, but I don't know for certain it was actually fixed properly on Vista SP2, and in fact it does seem it was not (considering the binary where this occurs wasn't updated).

Microsoft Deployment Toolkit 2010 (MDT) and WDS. Hands down, short of using SCCM, the easiest and best method to do a scaled out deployment.

No, this method is fine - in fact, you almost need to use slmgr to activate if you're going for automation. You should be able to do the above (assuming your MAK key is in the xml file correctly) and get fairly unattended setup and activation. If you still get stuck with an "OK" click, consider wrapping your slmgr steps in an autoit script or similar.

Windows XP's setup used the old NT setup engine, and you had to actually install XP from the flat source files, configure it, and then sysprep/reseal it. Windows Vista and Windows 7 are already images, sysprep'ed, from Microsoft, right on the DVD. If you want to edit an image, you can do the same as you did with XP, or you can use any of the myriad tools Microsoft makes available to edit Vista and/or Windows 7 images - WAIK, WDS, and MDT. In fact, if you're planning on *making* images to redeploy to your organization, I strongly suggest investigating whether or not MDT 2010 will meet your needs, as it likely will.

If you're moving hardware platforms entirely (V2P), you probably want to have sysprep -pnp -mini -reseal to make sure all new devices (PnP or not) are actually detected during mini-setup.

I actually found it to be MORE intrusive than regular Vista UAC, although it was a bit (and I stress, only a bit) more informational when prompting about what the program in question was attempting. You would probably be better served, if you aren't going to rely on inbox UAC, to use Norton's replacement. However, I've seen both Norton's UAC replacement and Smart UAC Replacement BSOD Vista boxes, so be warned. Honestly, you'd be better served with a good antivirus program, the firewall enabled, and regularly scan for mailicious software with the myriad security tools we talk about here. UAC might help protect most end users from themselves, but for the bulk of us here it's probably best just to disable it unless you need some functionality (like IE protected mode) that you cannot get without it enabled.

Chili is correct - what you want to do isn't a feature of Windows TS until 2008 (and even then wasn't robust until 2008 R2). If you need to do this on 2003 server, you need Citrix Presentation Server, period. This can be done with group policy, logon scripts, and ACLing things on the 2003 server, but it's a pain in the rear and isn't 100% a solution either as there are ways around things without Citrix installed.

Any browsers that support WPAD (either via DHCP or DNS, although DNS is preferred for cross-browser compat) can be configured to get proxy automatically. I believe Chrome, Safari, Firefox, and IE all support autoconfig via WPAD and a proxy script, and I'm unsure as to Opera's support (last I checked it didn't support WPAD, but I haven't tried 10.x yet). Note you'd need a web server hosting the wpad.dat file that WPAD points to on the network and DNS or DHCP to point to it as the autoconfig URL.

Note that Microsoft currently has no plans for a SteadyState for Windows 7, but they would likely be taking comments on it on connect if you had any - if you have a business need that you can post to connect to try and convince the product groups to make a Win7 version, you (and anyone else in the boat) should do so. I do not believe they've "killed" the product, but there are currently no plans to bring it forward from Vista for some reason (probably partially due to the fact that it's currently x86-only, and Win7 will be the last x86 client OS from MS, meaning they'd have to get an x64 version tested and working - just a guess, honestly, but probably not far from the truth).

Note that there currently is NO Intel IA-128 architecture, so this is a farce. Not only that, but it seems likely that the Itanic is never going to see a 128bit variant, as Intel is putting it's money and research into x86_x64 (amd64), just like AMD is. If there is to be a 128bit chip for PCs in the future, it will likely be a continuation of x86_x64 in some way. The Itanic is not the road to 128bit.

MDT itself can't activate Windows, as it's just a framework to run scripts in the OS (this part of setup is still controlled entirely by the Windows setup engine). However, it's purpose *is* to run scripts, so you could very easily leverage this by creating a new task in a task sequence to run slmgr.vbs to activate Windows - creating a set of tasks in the State Restore phase tree to run slmgr would work. The first step would be to run "cscript.exe %windir%\system32\slmgr.vbs /ipk <product key>" if we're not talking about VL keys (the slmgr switches would differ for a VL key depending on your KMS infrastructure, obviously), and then a second step to run "cscript.exe %windir%\system32\slmgr.vbs /ato" to activate that key.

Not without 3rd party software. Telling a package to run as admin, if you aren't logged in with the local admin account, will still require an elevation prompt and consent. Only the local Administrator account gets a "full" user token and is a *real* admin. Every other account, even other administrative accounts, are not granted a full permissions token when logging on, and must "consent" to UAC that you want to be granted that full token to run an application with full admin privileges. Note that you will get the same behavior in Win7 as well, and this is how UAC works (think su in *nix), and if you do not wish to be bothered then either use the actual Administrator account, or disable UAC.

Usually these errors are a result of "access denied" somewhere when loading the binary (the application error is indicative of a crash, and almost all of them involving ulib.dll involve crashing with the code 0xc0000005, access denied). I've seen this error many times, and always on Windows 2003 x64, and it was always a permissions issue. Running procmon.exe while attempting to run vrfydsk might show you where the access denied errors occur.

You can try the deploymentguys blog, although I'm not sure of a lot of documentation around these .ini files. Most of this stuff dates back to BDD2007. That might make a good blog post though - might be something you can request from them .