cluberti

Do NOT double post. [Closed].

Only if you're installing Windows, capturing it via imagex, and trying to deploy it to other machines. If you're using the original WIM file and simply using an unattend file to change settings and/or deploy applications, the original WIM file is already sysprep'ed from Microsoft. However, if you're installing Windows to a template machine, adding apps/drivers/etc, changing settings, and then capturing THAT to re-deploy, then yes, you must run sysprep.

Hard to say - might want to enable WDS logging to get some further info before we can help. It's obvious the TFTP download is failing, but as to why, dunno. You could also remove the WDS feature (and all of it's associated files) and re-install the role to see if it helps - it could just be a corrupt or missing wdsnbp.com file.

If you use vbscript or powershell, you can use the Win32_LogicalDisk class to determine which disks are fixed local disks (hard disks), and then use diskpart to clean/create/set partitions and format them.

Windows 7 is hardware independent, until you start adding things like chipset drivers and such. However, sysprep /generalize does a good job of removing those sorts of things, but I still prefer to use a deployment solution to add drivers and applications simply because you *can* (not will, but can) run into problems adding apps and drivers and sysprep'ing the image. Also, I like having a single (untouched) image with a set of apps and drivers, and using MDT task sequences to do all sorts of different things with them without having to have multiple images. Just a preference, I suppose.

It's actually not that different from one of my examples, Internet Explorer - specifically, IE8. It also runs on XP, Vista, and Win7, and will be supported on XP until XP's support EOL's in 2014. Hence why I think it will likely see the same support boundaries (it's not specifically listed on the lifecycle yet, only the MSE OEM pack is).

You'd have to install userdump and set it to dump svchost.exe on crash, and that will slow your machine down immensely (it may even cause it to crash itself). You could break each svchost service out into it's own servicehost, but that's pretty time consuming. It's up to you, but given the errors you posted, I'd lean towards a user-mode USB driver causing it (and we've already seen the ADSL modem driver in the error list).

Even if it's attached via ethernet, the USB driver for the ADSL modem is loading. If you installed any software for the modem when you got it, it would be best to remove it - you're not using it, and it's not behaving properly anyway.

All cut-off dates are artificial, because the vendor doesn't want to keep paying people to support something once there are multiple newer versions out - Microsoft has the longest OS support cycles of anyone in the industry, and they're 100% transparent about cut-off dates (Windows 2000 has been supported since early 2000, and will end 10 years later in July of this year for 10 full years of support, and Windows XP will be supported until 2014 from 2001, so 13 years!). Given the way Microsoft handles things like IE6 on Windows 2000, or IE7 and IE8 on XP (they follow the OS lifecycle, don't have one of their own), I would wager a guess that as long as Microsoft continues to make security essentials, they'll support it on the OS it's installed on until the support for that OS ends. It's how they handle things like IE, Windows Media Player, etc - so it would at least seem most likely that they would follow that tact with MSE as well - support the current version until a new version is released (and then likely 12 months for the "old" version until it expires), and supported on the OS it installs on until that OS support ends.

New thread opened in Win7 unattend discussions. Closing this thread.

Right - hence, call Microsoft. They'll provide you with a key that will install, but you'll have to use the phone activation to activate it (it won't activate online).

Perhaps run a .cmd file from the tool, and have the .cmd file call reg import .reg on all the .reg files you want to import? Seems simpler.

The problem isn't actxproxy.dll, it's likely your hlink/ieframe registrations have been overwritten with ones pointing to shdocvw.dll (IE8 doesn't use shdocvw.dll anymore, most everything got rolled into ieframe.dll with IE7 and shdocvw.dll is only left over for purely shell function calls). You could go about picking out and finding the offending registry entries with procmon, but it might be best to light that candle with a flamethrower (especially if it's a fairly new build) - there's a script here that'll do the whole thing for IE8.

Technically there's no difference between Server 2003 R2 and Server 2003 R2a other than the product keys used, but given that you have a 2003 R2a disc and are having trouble with the product key you might want to call the Microsoft clearinghouse for a key. If the vendor gave you a valid key (and it looks legit, although from a grainy photo it's hard to say for sure) and it won't activate, call Microsoft and get them to provide you with an activation key you can then use in the phone activation steps in the OS. That should be sufficient (you probably simply have a key that's either been activated before, or for some reason isn't matching the PIDkey that theOos is generating on install).

Also - POP3, IMAP, Exchange? What server type(s) are you attempting to connect to? More info is needed.

If it's access denied, then it's highly likely that the passwords don't match, or the keyring on one machine has stored an incorrect password. I'd try removing and re-creating the non-working account on both machines and try again.

The problem is ultimately this: 1.563: MyMakePerFileExceptionA: MakePerFileException failed; error=0x6ba. 1.563: Copied file: C:\WINDOWS\system32\DllCache\sysmain.sdb 1.579: MyMakePerFileExceptionA: MakePerFileException failed; error=0x6ba. 1.579: Copied file: C:\WINDOWS\system32\DllCache\aclayers.dll 1.594: MyMakePerFileExceptionA: MakePerFileException failed; error=0x6ba. 1.594: Copied file: c:\windows\$hf_mig$\KB955759\SP3QFE\sysmain.sdb 1.641: MyMakePerFileExceptionA: MakePerFileException failed; error=0x6ba. 1.641: Copied file: c:\windows\$hf_mig$\KB955759\SP3QFE\aclayers.dll 1.657: DoInstallation: Installing assemblies with source root path: c:\a5849f6a518b44520270b2713ca3\ However, the patch install was run in SP3GDR mode: 0.375: Hotfix started with following command line: /q /n /z /b:SP3GDR It's not attempting, for some reason, to copy either sysmain.sdb or aclayers.dll to \system32, only the \$hf_mig$ folder and \system32\dllcache - also, note it's trying to copy SP3QFE binaries, rather than SP3GDR binaries. The error itself is saying that RPC calls to delete the files fails, so that may be because you've manually attempted to delete the files (or it could be a bad service pack installation previously - it's one or the other). This would seem to indicate that AnalyzeForBranching determined that the hotfix should be installed in QFE mode, yet the hotfix keeps getting reinstalled in GDR mode which is why it keeps failing - it likely needs to update SP3QFE binaries, but is being run in SP3GDR mode. Did you use HFSlip or nLite, or another tool to customize this install? It's behaving as if everything installed is QFE, but the command line is telling it the binaries are GDR during branch analysis. You'll need to tell us more about these images, and how they were built, because I think the answer lies there.

Once you have a deployment share configured the way you want and you've created media, you simply need to take your litetouch_x86 and _x64 .wim files and place them on a server running Windows Deployment Services. At that point, you configure option 66 and 67 in your DHCP server to point to the WDS server and boot files, respectively, and then PXE boot a client (which should connect to your WDS server configured in DHCP) and pick the x86 or x64 litetouch image depending on whether you're deploying x86 or x64 images. It will boot the LiteTouch PE image, connect to the deployment share over SMB, and give you the wizard you step through to do your deployment. It's really rather simple - you just need your MDT deployment server, a server running the WDS role (which can be the same server) that contains your LiteTouch WIM files, DHCP options 66 and 67 configured to point to the WDS server and boot file, and a client that can PXE boot. If you're having trouble deploying images, one of the most common problems is the image itself (or screwing up the task sequence). I strongly suggest using MDT to deploy an uncustomized Windows client first, and once you're sure you have a client task sequence working on an uncustomized source, then consider adding applications and drivers into MDT to further customize the deployment. You really should only deploy customized WIM files directly from WDS - MDT should be used to CREATE the customized WIM files, and then capture them back. Think of MDT as your "lab", and once you have MDT and all of your apps working, then you use it to run the build again and capture that customized build. You take said customized build and place it into WDS, and use WDS to deploy that end-image.

With Server 2003 and Server 2008, doing this generally requires 3rd party security SSO software. It's a little easier with Server 2008 R2 environments (and the domain must be 2008 R2), but it's not 100% seamless: http://technet.microsoft.com/en-us/library/dd378897(WS.10).aspx http://blogs.technet.com/instan/archive/2010/01/15/enforce-smartcard-on-access-check-functionality-in-windows-2008-r2.aspx http://technet.microsoft.com/en-us/library/dd367851(WS.10).aspx You still need to consider an SSO solution if you want end-to-end smartcard logons for everything if you run legacy clients, but if you want to use a smart card for AD and security authentication, 2008 R2 domains/DCs can do it out of the box as long as the client is Windows 7 or Vista SP2. If you've got a mix, you will have to weigh the costs of upgrading to 2008 R2 and client OSes versus locking yourself into a different SSO solution.

The AMD dual-core and quad-core chips are all "real" multicore CPUs. Intel's original quad-core chips were the bridged processors (dual dual-core parts on one die), although they were only created for a short time before their quads were true quad-core parts.

The real question is why when you tell it to install does it still popup. Perhaps the KB955759.log file from a system where it fails attached to the thread might shed some light.

Not every time. I tend to say that a lot myself (because I think it's often very much the case and in many ways -- jscript is nice too), but for ridiculously simple things (e.g. starting an installer with a couple switches) it's just overkill. That depends on your view of simple. I prefer using something other than cmd simply because nothing ever stays "ridiculously simple" in my world. Give it time, it'll snowball into something that has to be migrated into a compiled app at some point, so I might as well use VBS or a Powershell cmdlet now, to try and stave off the inevitable longer.

First, sharing best practices is to create groups, not share directly with users. However, if you're using Win7 Home Premium you may not have any other options - best bet would be to create a share using the Advanced sharing button on the share tab, and make sure that both users have the correct sharing access from that window. Also, on the security tab, make sure both users have at least "read & execute" access to the physical folder being shared as well. It is also worth noting that if you've created a homegroup, the homegroup permissions ALWAYS override specific sharing permissions, so you might want to check that as well. Lastly, assuming you simply get access denied or your credentials for Paul are rejected after entry in the windows security box by the compaq laptop, it would be worth looking at a network trace to see what exactly is happening in the auth challenge handshake between the sony laptop as user paul and the compaq laptop when attempting to open a share as that user.

I don't think it's lazy, I think it is more likely the way the Facebook javascript APIs are written (for website integration by non-Facebook sites). The only way for Facebook to get access to determining that you are you through a 3rd party site is to use a cookie and a key (in this case, the MD5 hash). It actually makes sense to see it in the header if you think about how Facebook is modularizing and providing SDK access to the site. Or, it might just be developer indolence .