cluberti

You also need to look at the NTFS folder permissions - when someone connects over SMB to a remote share, the server hosting the share first checks a user's Share permissions (in this case, full control), but then it also checks NTFS permissions. Given Share has full control, you're likely failing at the NTFS folder permission level. You'll need to take a look at, and potentially modify, the NTFS permissions on that folder.

Well, what sharing and NTFS permissions are set on the share, and what user account are you using to try and access said share?

I looked quickly at the data, and there are an abnormal amount of NTFS calls, and I also notice that the Search binaries are abnormally active. This could be because of writing out the ETL log data, but I've not seen fltmgr quite this busy in an xperf trace in an awfully long time. What happens if you disable all of the Windows Search features? Also, a chkdsk /F /V /R /B might be in order on your boot volume.

The redistributable is usually the only package available outside of Windows Update for things like the MSI engine at this point, and the redist name generally means that an app vendor can redistribute this with their setup installer if they require a user to have a minimum version of the MSI engine on a machine before they run their installer. However, it's also useful for single-PC or multiple-PC rollouts as well, and as such you can download it and use it to install 4.5 of the MSI engine on your PC without worrying about the additions to the name, as they're just there to denote that the installation package can indeed be redistributed in certain ways.

You sure you've disabled TCP Chimney?

You're welcome and glad you pinpointed it. I figured that the once per week default of Windows Time was causing it to appear like a Windows issue when RedHat's ntpd updates at least every 17 minutes.

If you installed Win7, configured it, then want to use the new WIM, yes you must sysprep /generalize capture it before you can redeploy it anywhere but the original machine (and even that sometimes doesn't work). So yes, you must sysprep before you capture and redeploy, otherwise you're likely to have things just not work.

You're going to be missing the bootloader in that scenario. If you allow Windows 7 to create the 100MB partition during initial install, you're going to have to capture it. Hence if this is going to be a machine that's to be used as a master technician pc image, you should manually partition disks and install Win7 onto one singular partition to be safe and to have this work without using sysprep.

Does the install finish, and then Windows crashes, or does it BSOD during setup? Also, what's the bugcheck code in the BSOD itself?

You are correct, if the DFS replication doesn't happen and a file exists at both locations, you can get into version conflicts. Since DFS doesn't provide file locking, it *is not* a good solution for regularly edited documents. If your customer really must have DFS for file shares that are significantly active, there are 3rd party software tools to provide file locking, but it's an expensive solution to a poor implementation. DFS will still try to copy the older file (because the newer one will win the conflict) to the \DfsrPrivate\ConflictandDeleted folder inside the folder that the file is located in, but again DFS does not have any distributed file lock tracking mechanisms and is definitely not a good idea for document locations that will be updated frequently by multiple sites. Again, if you must, you should look into 3rd party file locking tools like PeerLock or similar. There are better alternatives too, however, that aren't file-server related - if you're looking to implement something for collaborative document sharing, Sharepoint is technically Microsoft's solution to this problem, coupled with WAN acceleration technologies at the remote sites and 3rd party solutions for geo-distribution (if you want to distribute the data load rather than centralize it). It's a bit aggressive, and the client may have gone with DFS because it was "free" and bundled with Windows, but DFS was most definitely *not* meant to store regularly updated collaborative data, again because of the aforementioned file locking and version conflict issues. It just isn't good for that - it's good for things like user profiles, DR data, read-only archives, etc, but if you have a "collaboration share" where lots of users are updating lots of files, DFS is most definitely not the first (or second, or third) option I would have considered because it just isn't designed for that kind of workflow.

From the WUD site, specifically the UL download page:

Long-time Cubs fan here, which means I'm a glutton for punishment. Love going to games though, Wrigley is up there with Yankee Stadium and Fenway as places all baseball fans must get to at least once in their lives.

1. NTFS and Share permissions configured on the file server handle this 2. NTFS permissions on a folder configured on the file server control this 3. This would be client-side, and short of using Microsoft DRM servers in your network to control access you'd have to look at 3rd party security tools for this 4. Auditing of files and folders on NTFS volumes can handle this, although on a large scale this can be cumbersome and you would have to look at 3rd party tools for this

Hard to say - ZoneAlarm is pretty good, and it's made by CheckPoint software out of Tel Aviv.

Recovery from sleep failures are almost always driver related. You can blame the OS if you'd like, but if it were an OS bug you might have heard more about it on a large scale, found a KB about it at the very least, and given Win7's been RTM since September 2009 there would be a fix for an OS bug that bad by this point. The hardware seems fairly standard, so I wouldn't be able to pinpoint it from a list, but using the directions here might help you pinpoint the culprit.

It's actually well-known that VS 2008 just can't be slipstreamed in any supportable way (see here). In fact, even file replacement seems to break installs, meaning you have to script it. There are some workarounds posted (like this one), but they tend to not be 100% reliable - for example, the resulting installation from this method worked on my XP workstation with SP3, but it did not work properly on my Vista SP2 or Win7 box at all. For my own unattended installations, I simply install the prereqs for VS 2008, do a custom install of VS 2008, then install SP1 unattended (setup.exe /q /full).

If you've got a network switch that can mirror ports, you could "remotely" monitor traffic to or from another machine by simply monitoring the mirrored port.

The solution is gonna involve some investigative work by you to help us, because the MSFN crystal ball is in the shop currently. Please start by running hijackthis on the affected machine and attach the log to your next post here, for starters. We're really bad even with the crystal ball at guessing, but pretty good once we have data .

Just because you built a PE image on a machine doesn't mean it has that machine's drivers built in (it doesn't - and in fact, PE has far fewer drivers than the full Windows OS, for obvious reasons). Also, you can use the WAIK for Windows 7 on Vista and 2003 machines (no XP support, but 2003 SP2 and newer), so I would suggest downloading and using the Win7 WAIK on your Vista machine to create a WinPE 3.0 image before giving up . Instructions for making a custom PE image with the Win7 WAIK are on Technet here.

Apparently there are a few of you failing the rules. Locking the post, let's try not to flame each other next time, eh?

Worked for me using WinRar. I assumed 7-zip would work (has in the past), but I guess not on those. WinRar worked fine.

If you have a 32bit app, it would be better to find the native x64 version (if it exists) or use something compatible if possible. If you absolutely must have the 32bit app, you could consider a virtual machine rather than a dual-boot.

The drivers you should need are listed in that article. However, they ship from dell as self-extracting .exe files - you can bypass Dell's installer by using a tool like WinRar or 7-zip to extract the files from the .exe itself, and then use those extracted files in nLite.

If a 32bit app requires a 32bit driver, like a filter driver (antivirus, firewall, security software, etc), then no, this is not possible. You cannot load a 32bit kernel driver on a 64bit system.

First I'd try creating a WinPE 3.0 disc from the WAIK for Win7 to see if that finds it, and if not you're going to have to use DISM to add the SATA chipset drivers to your PE disc before it'll find a hard drive.