cluberti

Are you setting these in group or local policy, or just manually entering them via a .reg import?

To unattend a Windows 7 install from WDS, you need an unattended file for the Windows 7 image, as well as the Windows PE image.

You want to look towards the end-points of the certifications, not just which individual ones to take - these aren't teaching you anything, they're supposed to test your knowledge on what you've already learned or accomplished. As to which to look into, consider following tracks in the MCITP roles under the desktop client (suggestion of Enterprise Desktop Administrator) in addition to an MCTS in Windows 7; if you are considering the admin role in the future, the MCITP Server or Enterprise Administrator should be on the list. In my opinion (and it's just that), getting something like an MCTS in Windows 7 is nice but unless you have a broader certification to go with it, it means far less (especially if you don't have a lot of demonstrable work experience in that area in your past). Being able to pair certifications (for example MCTS Windows 7 Configuration + MCITP Enterprise Desktop Administrator + MCTS Business Desktop Deployment) makes you far more valuable, and will also show to others that you know quite a bit about the end-to-end of desktop deployment and administration. Make sense? My suggestion is always to take tests and create and follow tracks towards overall goals, rather than doing them piecemeal. It'll take a bit more time and effort, but will definitely get you farther ahead in the end.

If you've ever used Windows 7 in an administrative role, you should be able to pass this test easily. As trip said, you need a 700 to pass (just like most other Microsoft certification tests).

Is it just that site that is affected? If you add other sites to the trusted sites zone, do they also go to Intranet?

Uh oh - dump is corrupt: ************************************************************************** THIS DUMP FILE IS PARTIALLY CORRUPT. KdDebuggerDataBlock is not present or unreadable. **************************************************************************

Oh, I actually thought it was buried on some Microsoft page.. Ha Ha. Man i feel DUMB! Thats probably why Tripredacus said silly you .. or i don't know what to think???? Thats why i asked is it legal for me to use and then he posted the link and i thought... Anyways Well, if you do install the Windows 2000 Resource Kit, you can use the link trip gave you to get sysdiff. You can't just download sysdiff itself though, you need the reskit and the hotfix package, but I'd still suggest not using it and use things like regshot and procmon.

I'd like to see one or two more of these - if they're all random, then the above could just be because of bad RAM, unfortunately. I'd like to see more to make sure my analysis above isn't just a victim of some other cause. If they're all 50 and 8E bugchecks, however, this could actually be a filesystem or filter driver issue.

This is interesting: 1: kd> .trap 0xffffffff8972997c ErrCode = 00000000 eax=86644b00 ebx=00000000 ecx=807d18f2 edx=00010006 esi=866421e0 edi=89729cac eip=81c5df62 esp=897299f0 ebp=89729ab8 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 nt!IopParseDevice+0xd38: 81c5df62 8b4b3c mov ecx,dword ptr [ebx+3Ch] ds:0023:0000003c=???????? 1: kd> kb *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child 89729ab8 81c4c5e1 850cc0a0 00000000 864aab90 nt!IopParseDevice+0xd38 89729b48 81c59b62 00000000 89729ba0 00000040 nt!ObpLookupObjectName+0x5a8 89729ba8 81c3eed2 0014f788 00000000 81c5f401 nt!ObOpenObjectByName+0x13c 89729d54 81a69c7a 0014f788 0014f760 0014f7a8 nt!NtQueryAttributesFile+0x125 89729d54 773c5e74 0014f788 0014f760 0014f7a8 nt!KiFastCallEntry+0x12a 0014f740 773c4d60 76d4d2d3 0014f788 0014f760 ntdll!KiFastSystemCallRet 0014f744 76d4d2d3 0014f788 0014f760 0014f800 ntdll!NtQueryAttributesFile+0xc 0014f7a8 75c84dca 004fca10 00000000 0014f7e4 kernel32!GetFileAttributesW+0x5a 0014f7b8 75c85ae8 004fca10 004fb45c 20008000 SHELL32!kfapi::CFolderPathBuilder::Verify+0xf 0014f7e4 75c84e0e 004e92f8 20008000 004fca10 SHELL32!kfapi::CFolderPathBuilder::Create+0x92 0014f804 75c85890 0014f960 004e92f8 20008000 SHELL32!kfapi::CFolderPathBuilder::VerifyAndCreateFolder+0x24 0014f894 75c84f16 0014f960 00000000 20008000 SHELL32!kfapi::CFolderCache::GetPath+0x2ad 0014f8f8 75c84e78 0014f960 20008000 00000000 SHELL32!kfapi::CKFFacade::GetFolderPath+0x5d 0014f918 75c858fa 0014f960 20008000 00000000 SHELL32!SHGetKnownFolderPath_Internal+0x38 0014f934 75c7a0cd 0014f960 00000000 00000000 SHELL32!SHGetFolderPathEx+0x30 0014f974 0034dacb 00000000 0000801c 00000000 SHELL32!SHGetFolderPathW+0xac 0014fd4c 0034a91c 00340000 00000000 004d205e SearchIndexer!WinMain+0x1f3 0014fddc 76d4d0e9 7ffd9000 0014fe28 773a19bb SearchIndexer!__mainCRTStartup+0x140 0014fde8 773a19bb 7ffd9000 77561c5a 00000000 kernel32!BaseThreadInitThunk+0xe 0014fe28 773a198e 0034c9ad 7ffd9000 00000000 ntdll!__RtlUserThreadStart+0x23 0014fe40 00000000 0034c9ad 7ffd9000 00000000 ntdll!_RtlUserThreadStart+0x1b 1: kd> .printf "%mu", 0x96923a70 \Device\HarddiskVolume1\Windows\system32\config\systemprofile\AppData\Local 1: kd> dds 897299f0 89729ab8 897299f0 a4136dfe 897299f4 864aac34 897299f8 850cc088 897299fc 00000000 89729a00 00000002 89729a04 00000000 89729a08 8363805c 89729a0c 00000000 89729a10 864aab90 89729a14 00000080 89729a18 00200000 89729a1c 000000a8 89729a20 000000a8 89729a24 656c6946 89729a28 00000000 89729a2c 000007ff 89729a30 803da001 89729a34 86640418 89729a38 866540a8 89729a3c 00000000 89729a40 89729aa8 89729a44 00000000 89729a48 00000000 89729a4c 81c4d0ea nt!ObpFreeObject+0x192 89729a50 86654008 89729a54 00000000 89729a58 00000000 89729a5c 807d8bc4 fltmgr!FltpFastIoQueryOpen 89729a60 86654028 89729a64 864aab90 89729a68 00000000 89729a6c 86654008 89729a70 864aab90 89729a74 00000000 89729a78 00000080 89729a7c 00000000 89729a80 00000000 89729a84 8510ded8 89729a88 00000000 89729a8c 850cc0a0 89729a90 89729cac 89729a94 84d531a0 89729a98 00000000 89729a9c c500d120 89729aa0 897299f0 89729aa4 89729458 89729aa8 89729d44 89729aac 81a46ce9 nt!_except_handler4 89729ab0 acc67ed6 89729ab4 fffffffe 89729ab8 89729b48 Usually I don't see things like this unless a filter driver failed (it's a stack pointer error), but I don't see the call to IofCallDriver here - it could be that it failed before the box dumped, or the error caused it before we could walk the filter driver list to handle this. Assuming there are no permissions issues on this folder (this process looks like it requires write access to the system's %USERPROFILE% location), so you might want to disable indexing entirely and see if you get another crash. I'm still suspicious here about this though, it has an active IRP at the time of the failure - it might be relevant, it might just be white noise, but... 1: kd> lmivm cdrbsdrv start end module name 8bbf7000 8bbfee00 cdrbsdrv (deferred) Symbol file: cdrbsdrv.SYS Image path: \SystemRoot\System32\Drivers\cdrbsdrv.SYS Image name: cdrbsdrv.SYS Timestamp: Tue Jun 16 23:37:15 2009 (4A3864EB) CheckSum: 00013E19 ImageSize: 00007E00 File version: 8.1.1.0 Product version: 8.1.1.0 File flags: 8 (Mask 3F) Private File OS: 40004 NT Win32 File type: 3.7 Driver File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: B.H.A Corporation ProductName: B's Recorder GOLD InternalName: CDRBSDRV.SYS OriginalFilename: CDRBSDRV.SYS ProductVersion: 8. 1. 1. 0 FileVersion: 8. 1. 1. 0 PrivateBuild: 8. 1. 1. 0 SpecialBuild: 8. 1. 1. 0 FileDescription: CD-ROM Filter Driver for Windows2000/xp LegalCopyright: Copyright (C) 2000-2009 B.H.A Corporation LegalTrademarks: Copyright (C) 2000-2009 B.H.A Corporation Comments: Copyright (C) 2000-2009 B.H.A Corporation It appears you were playing the file off of the CD drive, hence my suspicious nature of this - here's the devnode (\device\disk) showing the hard disk, the ecache (decompression) IRP from WMP that comes from it, and the IRP it's waiting on (atapi.sys): 1: kd> !DevNode 843fa8b8 DevNode 0x843fa8b8 for PDO 0x84400030 Parent 0x83a82ad0 Sibling 0000000000 Child 0000000000 InstancePath is "IDE\DiskWDC_WD10EADS-11M2B1_____________________80.00A80\5&228e3881&0&1.0.0" ServiceName is "disk" State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) StateHistory[08] = DeviceNodeEnumerateCompletion (0x30d) StateHistory[07] = DeviceNodeEnumeratePending (0x30c) StateHistory[06] = DeviceNodeStarted (0x308) StateHistory[05] = DeviceNodeStartPostWork (0x307) StateHistory[04] = DeviceNodeStartCompletion (0x306) StateHistory[03] = DeviceNodeResourcesAssigned (0x304) StateHistory[02] = DeviceNodeDriversAdded (0x303) StateHistory[01] = DeviceNodeInitialized (0x302) StateHistory[00] = DeviceNodeUninitialized (0x301) StateHistory[19] = Unknown State (0x0) StateHistory[18] = Unknown State (0x0) StateHistory[17] = Unknown State (0x0) StateHistory[16] = Unknown State (0x0) StateHistory[15] = Unknown State (0x0) StateHistory[14] = Unknown State (0x0) StateHistory[13] = Unknown State (0x0) StateHistory[12] = Unknown State (0x0) StateHistory[11] = Unknown State (0x0) StateHistory[10] = Unknown State (0x0) StateHistory[09] = Unknown State (0x0) Flags (0x00000130) DNF_ENUMERATED, DNF_IDS_QUERIED, DNF_NO_RESOURCE_REQUIRED 1: kd> !irp 86633438 Irp is active with 8 stacks 4 is current (= 0x86633514) Mdl=85779f18: No System Buffer: Thread 862a2850: Irp stack trace. cmd flg cl Device File Completion-Context [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 >[ 3,34] 10 e0 84c50608 00000000 8070f134-00000000 Success Error Cancel \Driver\disk partmgr!PmReadWriteCompletion Args: 00001000 00000000 dbb10000 00000008 [ 3, 0] 10 e0 84c50230 00000000 8071e4d4-84e563c0 Success Error Cancel \Driver\partmgr volmgr!VmpReadWriteCompletionRoutine Args: 090b6192 00000000 dbb10000 00000008 [ 3, 0] 0 e0 84e56308 00000000 8799e9ac-850d0c20 Success Error Cancel \Driver\volmgr fvevol!PassThroughCompletion Args: 090b6189 00000000 dba10000 00000008 [ 3, 0] 0 e0 850d0b68 00000000 87976cc6-86640118 Success Error Cancel \Driver\fvevol ecache!EcDispatchReadWriteCompletion Args: 00001000 00000000 dba10000 00000008 [ 3, 0] 0 0 850d1690 00000000 00000000-00000000 \Driver\Ecache Args: 00001000 00000000 dba10000 00000008 1: kd> !irp 845118d0 Irp is active with 3 stacks 3 is current (= 0x84511988) Mdl=85779f18: No System Buffer: Thread 00000000: Irp stack trace. cmd flg cl Device File Completion-Context [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 >[ f, 0] 10 e1 84400030 00000000 879cf138-850cc538 Success Error Cancel pending \Driver\atapi CLASSPNP!TransferPktComplete Args: 850cc5e4 00000000 00000000 84e56600

It's not, which was the other reason I was trying to steer you away from it .

Chrome is installed into <user>\Appdata anyway, so why preinstall it? Why not install it once the system is up and running (there's an offline installer for that, or just download and run the stub that installs it online)? Other users aren't going to have access to the program anyway, as it's a per-user install.

For what it's worth, that error is: # for hex 0x80010100 / decimal -2147417856 : RPC_E_SYS_CALL_FAILED winerror.h # System call failed. Given making a call to the interop gives that error, I am guessing you are doing this from an asp.net app or inside a COM application itself - I may be wrong, but I can't think of how you'd run into this from an actual user session in a .net app. You might want to take a look at this KB, and make sure you're OK with where you are. My guess is this is failing with a user permissions error, rather than the generic error that bubbles up. You could run procmon on the client and see what you might see, but it's worth noting Microsoft doesn't support what you're doing, so you're on your own at this point. Again, given the fail, it's either a problem running it inside a service and breaking out to COM, or a permissions issue (or both) likely.

I like your first idea, which is how MDT does it. And, considering, have you looked into using MDT for your deployment?

No, and I'm all for giving users tools to help them troubleshoot (if possible) and avoid the service calls, because a few dollars up front is much easier to budget for than an unknown number of dollars later. Plus, people are expensive, but a user's time (speaking as the OEM) is not - give them media and instructions on how to use it, and I'd bet it'd be a good-will gesture and a money saver overall.

One way to restrict software is to not allow them to be administrators on the machine. Without admin rights, most software packages will fail to install (without admin approval via the UAC dialog or installation via group policy or SCCM or some other software installation method) as the user really only has write access to most folders in their profile and most locations in their HKCU registry hive. Another is to use the Applocker feature of group or local policy to lock down which applications, scripts, etc. are allowed to be run by specific users or groups. There's a more in-depth overview of it here, as well as a checklist in-depth walkthrough of it here.

Let us know how it goes. In response to a previous question, the caveat of the .lnk/.dll exploit is that it has to go through control panel .lnk handling code - the regular OS .lnk handler doesn't appear to have the vulnerability, but whatever is happening specifically with the control panel does (I haven't really debugged it much further than has already been done, because I don't really care much more than that).

The only caveat is, say that HP sells ~18,700 PCs in 2009 (they did), and they save roughly $6.00 per unit (the licensing agreement from the vendor is cheaper if you provide recovery media only, and also you don't have to contract out minting and printing (and shipping) media as well). That's $112,000 more in a fiscal year that they've saved, at least on paper. I would wager it's probably far less if they have to deal with a lot of support requests related to the restore/repair partiton or media creation, but beancounters rarely take this into account when they push management to make these decisions. Support is already factored into the cost of some of the machines, with the intention that only a small percentage will actually use it (which is true). However, if support costs for these wipe out the meager savings you get by not providing media (or at least providing an easy way to get a replacement online or over an automated phone), then it would make sense to put the "savings" back into the support pool and buy the media.As all of us who have or do work for large corporations know, sometimes they do the dumbest things to save a buck (and end up probably not saving much in the process anyway). For every good idea, there are likely any number of dumb ones that don't work.

That's not a problem of WDS though, as it knows nothing of XP sysprep (nor can it do anything about it). That would lead me to believe the problem occurred during the sysprep.

If you're seeing questions, it means your sysprep.inf didn't include the answers. This is stored on the XP install in C:\sysprep, along with the sysprep.exe binaries. You must place this here BEFORE you run sysprep, as you cannot mount an XP WIM image and edit it offline like you can a Vista or Win7 image.

You run sysprep on the XP system once it's ready to be captured, and it reseals the system. You don't have to put it anywhere else, just capture the XP system to a .wim file, place it on the WDS server, and use WinPE to deploy it to clients.

http://www.msfn.org/board/topic/121503-the-compiled-faq-guide-thread/page__view__findpost__p__788433

There's only one problem with your post - nLite is expressly forbidden for use for anything other than personal modification of your personal XP source (read the EULA sometime). I strongly suggest you cease and desist use of nLite in your corporation, and stick to just modification of winnt.sif. There's no reason to use nLite for this anyway. As to the problems with setup, I'm guessing the original XP CD had the IBM disk controller drivers integrated into it, and your customized CD does not. It would make sense to integrate these drivers if possible anyway, that way you wouldn't have to use the older IDE compatibility mode, and use the preferred AHCI. It's even discussed here already.

Yes, they are in both - but a lot of those are the defaults (rather than their 64bit counterparts) like IE or WMP. Removing Program Files (x86) will likely do more harm than good, although if you want to try it and report back the results, that might be interesting.

That looks like an overflow error on the web server itself, given the error. Global.asa is an optional ASP file that defines methods and functions that can be called from the site. My guess is there's something at line 42 of that file on the web server that has a SQL connection that's failing. In short, we're not going to be able to help you fix something that isn't broken on your end - right now, your best bet is to send an email to webmaster@<domain of site in question> to let him or her know their SQL statement in global.asa or database on the backend is having problems.

If it happens every time, you might want to run a process monitor while sysprep'ing, with a filter perhaps on sysprep itself.