cluberti

Interesting indeed, although that would sound more like MFT issues than an actual NTFS issue. It might be worth booting from WinPE and doing a chkdsk and defragmenting offline, then rebooting. It might also be worthwhile to increase the MFT space, as MFT fragmentation can be an issue in misreporting data (and apps that read raw disk data would likely be correct, whereas the shell would be wrong). The default value for NtfsMftZoneReservation is 1, and for most systems 2 should be sufficient. Only use 3 or 4 if you plan to store LOTS of files on a volume - otherwise, you'll waste space on the disk and limit the number of files that can be safely stored there. Note that this does work better on a freshly formatted volume, but changing it, rebooting, defragmenting offline, booting into Windows, rebooting, and then defragmenting offline again (online if XP or higher is fine, as defrag can do this online in XP or higher) should make headway into this problem. If this is an NT4 or 2000 system, however, you're going to have to offline the drive to fix this.

It's worth verifying if the reboot is doing something to the driver - for example, uninstall/reinstall and test, and then leave the system on for a few hours (or overnight, better) without going to sleep or hibernating. Check again after the elapsed time, and see if it still works. If so, then a reboot is likely to stop it from working again (which you can easily test). If so, it would sound more like a driver issue than a hardware one.

If you've configured the same usernames and passwords on both machines, you don't - NTLM authentication will use the logged-on user's credentials first (after the anonymous challenge from the client to the remote host inevitably fails). NTLM will then try with credentials in the credman store, and if those fail the current user's credentials are tried next. Only then, if all of the above fails, will you get prompted for credentials. In your case, credentialing works (you're logged on with a user and password that matches the remote machine - you're in!!!! Not good if you want to connect with a different user account ). Simple fix if you'd like credential prompts when making SMB connections between machines (and you should - good on you for trying to be secure)? Don't create the same usernames on two workgroup'ed machines (or at least don't use the same passwords). More complex? Open a cmd prompt and map a drive to the remote server\share, and provide explicit credentials to the net use command.

Seems the most likely culprit, given that the specific function in your error message from the .NET runtime is a broadcast event. Unless you have a service or taskbar applet running that is .net based, it's an explorer shell extension. Whatever it is, it's trying to broadcast a window change event (which goes through shell32 to explorer, which handles... the shell ) and something has hung it up. Might be worth using autoruns to disable anything non-MS that isn't necessary to boot before you leave at night, reboot, and then leave the system up overnight. When you come back in the morning, see if it is the same or if the problem does not appear.

Also note that if you just want to avoid the choice in the installation sequence, you can change ei.cfg on the DVD to force a different version without having to create an unattend. That is the only difference between a retail Home Premium and Ultimate DVD from Microsoft, for what it's worth - the contents of one file.

Firewall blocks these ports by default. To disable connecting to COM, however, would break both local AND remote COM. Also, you'd break RPC and a LOT of other OS functions. The firewall should be sufficient.

Agreed - the error complains that a particular function in iertutil cannot be found, and I've only ever found this to happen in two scenarios - one, something has broken iertutil's registration with an incorrect version (and thus the proper version from %windir%\system32 - and also %windir%\syswow64 from a 32bit cmd prompt on x64 systems - needs to be re-registered via regsvr32 /i) and two, an application designed for use only in a specific newer version of IE (IE7 or IE8, for example) does not work on a system with a lesser version installed (IE6, for example). Since you posted this in the Win7 section, I'm going to assume Windows 7 and IE8, which is likely to make scenario number two irrelevant, and leave you at #1. Further, given you had malware cleaned from your machine, this makes it even more likely that it is scenario #1.

Good workaround - you can do this with lots of packages, not just RSAT - anything that comes in an MSU can be extracted and force-installed (well, almost anything). However, it does only install the RTM bits, as you said, whereas having the tools installed and then upgrading to SP1 does upgrade the RSAT binaries to SP1 levels. Just as long as people are aware of possible issues, bugs, and limitations of using the RTM tools on an SP1 system, and are willing to take those risks, I say go for it .

That IP address was indeed banned yesterday for some reason - I'll see if I can look into that. In the meantime, things should work normally again. If they do not, please PM myself or Trip in response as necessary.

Please put nlite questions in the nlite section of the forums. Moving.

Please post questions about RT7Lite in the stickied thread. Thank you.

I would agree with Kels. Uninstall SP1 and go back to RTM, and see if the options are there. I have them on a few machines (Intel and AMD), and it's lacking on a few others - those options will only show if the processor driver Windows is using supports those features, and they're enabled and being read properly from the BIOS during boot.

1. For remote assistance to work, you need to make sure the remote tab in system properties is set to allow remote access from at least NLA devices (if you're trying to connect from XP or 2003 machines, you'll need to choose the second option for "all versions" instead). 2. The user account that is trying to connect needs to be in at least the Offer Remote Assistance Helpers group on the Win7 machines, or in the Administrators group (or both). Otherwise, you won't be able to connect. 3. You probably want to make sure you've configured policy (either local or group policy) to configure remote assistance settings on the Win7 machines. 4. Last, for printers, you need to connect to the print server (just \\server) from a Win7 PC, click "View remote printers", and then use "Add a printer" or right-click a printer, go to it's properties, click the "Advanced" tab, and click the "New Driver" button to add a Win7 driver (from the Win7 machine).

It requires tools in the OPK that don't exist in the WAIK, so this may be a no-go without an OEM account.

Microsoft documentes these things here: AD Certificate Services Migration Guide AD CS Migration: Migrating the Certificate Authority How to move a certification authority to another server Basically, you need to back up the current CA, remove the CA server from it's existing server after a successful backup, install the new 2008/R2 server, and restore the CA to this new host.

For those of us in the United States and/or covered by US law, copying a Windows source or downloading it from anywhere other than Microsoft, a licensed OEM, or a licensed reseller, is technically illegal - it's a violation of copyright. The sale of an OEM machine *must* include everything (software-wise) that shipped with it, including the disc (or recovery partition intact), the COA sticker, and any other documentation or product materials for Windows, Office, and/or any other OEM software purchased with the machine. Any sale without this is technically not considered a legal transfer of the license, which is in violation of the EULA. If you are in another country and covered by the laws there, they may be different. They usually are not, but it's always best to check. Given I do not know a lot about laws in, for example, Belgium or Brazil, I do not feel confident enough to say for sure if this is entirely illegal in places such as those. It is likely, but one should always verify against their own country's laws before deciding one way or the other. Going forward, whether or not someone would choose to do something like this on their own time is not for us to decide, but to answer the parent's question, yes, doing such a thing is indeed illegal in the United States (given this person listed their location as such, this would apply to them). The OEM copy of Windows on an OEM computer is tied to that computer only, and the OEM must provide (to the original purchaser) either installation media or a recovery partition that can be used in lieu to reinstall the OS. Again, we are not the internet police, so I won't comment one way or the other on what people do in their own time outside of MSFN. However, in the interest of keeping things here legal (we are based in the US, and governed by US law) and following our own rules, I am closing this thread. Since the OP wasn't specifically asking *how* to bypass security, and whether or not something was legal or not, I am not providing any warnings this time. However, do note that further discussion of illegalities that violate our forum rules will result in moderation. Thank you to everyone for complying with this request. [Closed].

Yes, you can use the web front end - note it requires you use the database, which may or may not be required depending on your config. Are you planning on letting others edit/update/create task sequences and such? If so, this starts to make more sense. If you plan to have a small number of "creators", then using the deployment workbench is easier.

In MDT, a task sequence is the actual sequencing of deploying the base WIM down to the client, injecting drivers, installing applications, etc. Basically, MDT allows you to do repeatable installations (and capture the result to a WIM to re-deploy, as necessary). There really isn't much need to "customize" a Windows WIM at all when using MDT - the task sequence does that.

It is better to use task sequences and answer files rather than create multiple images. It's a bit harder on XP because it takes longer to install a flat-file XP image, but it does give you more flexibility in the end (no 'lock-down' once an image is sysprep'ed, for example). Usually what I do is create a base task sequence that installs all the common software I need (after adding the applications to the applications node in deployment workbench and then hiding them), and put that in a group in the TS. Then, you have to decide if users get to pick and choose software from the wizard, or if you're going to direct this from Task sequence steps (either separate task sequences or WMI or variable queries on each step in a base task sequence). It can get pretty intricate, but it's not complicated. What exposure or experience level do you have with MDT right now?

Your MSI logs are from 1/2/2011, but your CBS log (because it rolls over) only goes back to 1/30. These are not useful, so please do this - disable the Windows Update service, try the install again, and when it fails, upload the latest cbs.log and MSI logging logs. I will need to see them both from a failed install to have any clue what's happening. You can of course re-enable the WU service after uploading the files.

What specifically are you trying to accomplish (above and beyond deploying images, of course)? You shouldn't really ever need to create an image at all - use the stock WIM off the Windows CD or the flat XP install source and customize with MDT. Knowing more about what you're trying to do should help us get you answers .

If you're using 2008 R2 Hyper-V, you can use Cluster Shared Volumes (CSV) in your cluster. This can be done over iSCSI (in fact, I set these up all the time). Just be aware of the speed you will get on your NAS and iSCSI before moving over, to make sure performance is acceptable. Some NAS devices are faster than others, and some iSCSI implementations are faster than others (using a fast NIC on a fast network isn't always going to bring you 100% success, so having a dedicated iSCSI HBA is always recommended). With all that said, you must be aware that the external storage device must support SCSI-3 persisitent reservations, and I don't believe the device you purchased does this. That would mean it would fail cluster tests, and as such would not be supported in a cluster configuration. You could probably still use the device as a mounted drive, but it would not be clusterable as shared storage (failover would... fail ). Note that FreeNAS does support this, so if you wanted to set up your own NAS solution for this, it could be done with free software.

Whatever is happening is happening outside of the MSI engine. It might be more useful to post your cbs.log from \Windows\Logs\CBS, or perhaps the setup*.logs in \Windows. Both would potentially provide data - this is happening below MSI, whatever it is.

If someone has dumps of it occuring, then that person or organization should be notifying Microsoft. Telling them is one thing, but without data it makes it really hard to fix .

Or, use procdump from sysinternals to get a dump of the spooler service crashing, and then zip or rar it up, upload it somewhere, and we'll take a look. Band-aids are fine for temporary pain relief, but actual answers and fixes are much better long term. A crashing spooler likely means a misbehaving print driver, so identifying the root cause shouldn't be too hard.