Duke5A

I read your original post wrong... Try this... Find the appropriate key from the link below and change both the key in your VM install, and in the answer file to match. When using one of these keys Windows will try to activate against a KMS first thing. KMS Client Setup Keys If I had to guess, your image right now is trying to activate directly with Microsoft with some key and completely bypassing your KMS server.

I wonder if the physical host has virtual NICs created on it for talking to locally hosted VMs. The subnet that these NICs are addressed with probably aren't routable and thus can't get to the domain for authentication. Give a look inside the VM and disable any NICs that aren't connected to the physical network. This might have something to do with your authentication problem.

What are you building the image on? I build mine (XP and 7) in virtual machines and use snapshots. When I first created the installs I fed them a MAK key and right before I get ready to run sysprep I shut them down and create a snapshot. When the sysprep/capture process is complete, I revert back to that snapshot.

Have you added the new subnets you created to Active Directory Sites and Services? This will cause issues similar to what you're experiencing.

Does your wireless network use predefined keys or do they authenticate against a RADIUS server? If you use a RADIUS server you can define the network connection in group policy. Computer Configuration\Policies\Windows Settings\Security Settings\Wireless Network (802.11) Policies I use this for our student netbooks and it works without a hitch.

ZenControl.zip I tossed a VNC launcher together in VB .Net 4 a while back and we use this for jumping onto teacher's machines for support. In a nutshell, it'll copy the required files to a temp folder in the C drive, create the registry keys on the client machine, register TightVNC as a service, start the service, and automatically connect the viewer from your workstation the teacher's machine. Once the viewer is closed on your machine, the registry keys, service, and files are removed from the teacher's. It requires that you have these things configured in the computer you're try to connect to: the remote registry service enabled, port 5900 open on the firewall, remote administration open on the firewall, and Secure Attention Sequence enabled and set to services. After that you'll be able to freely connect to client machines with, or without a user logged into them. It's still a little rough around the edges and I plan on rewriting a good portion of it soon. I hope some of you here can make use of this...

It's not the most elegant solution, but at least it is an option now in 2008. I haven't had a chance to implement this yet though, so I can't say how well it works. Fine Grained Password Policies-PSO

UAC is disabled in my environment as well. We're running about 400 or so Windows 7 workstations. I kept it disabled in the Pro image, but when we started migrating to Enterprise I tried keeping it on and it just proved to get in the way. Even with it being disabled, I see far less malware problems on 7 than I do with the XP machines that are still hanging out there.

Every time that I've seen this it has always been malware for me as well. I know this is for Windows XP, but these registry exports look similar to that of Windows 7. They've always worked for me in XP in the past. Can't hurt to try, right? Windows XP File Assocation Fixes

Are there any other services running on the box? DHCP? SCCM?

I use the following code in our VB logon script with no issues whatsoever in Windows 7. As far as your own script only working if you run by hand might have something to do with UAC though. Set objWMIService = GetObject("winmgmts:\\.\root\cimv2") Set colInstalledPrinters = objWMIService.ExecQuery("Select * from Win32_Printer",,48) On Error Resume Next For Each objPrinter in colInstalledPrinters objNetwork.RemovePrinterConnection objPrinter.Name Next If Error <> 0 Then 'Just catch the error, moving on Else 'Nothing to see here folks, move along. End If

I can't speak for the equipment you have, but with Cisco hardware you would need to enable IGMP Snooping to properly handle multicast traffic in a VLAN segment.

Try deleting the local profile for that user and let the machine recreate on the next log on. If it's still doing it after that then I would run RSOP.msc and verify how the policies are being applied to the user.

FYI, DO NOT implement this policy with the machines still frozen as they will immediately request a new machine password when this happens. Once they reboot, they'll revert to the old password and the machine account will be borked. Don't ask how I came to find this out.

Your not going to be able to set something like that through the MSI. Give this a look at... http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/flashplayer/pdfs/flash_player_11_3_admin_guide.pdf You're probably going to have to create a custom mms.cfg file and use a script to copy said config and install Flash. On another note, I have no idea why these settings aren't kept in the registry. If they were it would be trivial to write a custom ADM template to set them.

If that's the problem (which it probably is), I'd be more inclined to disable System Restore instead of changing the default inner workings of AD. Machine accounts changing their passwords every 30 days is for security.

I had this happen once when a teacher brought in a Linksys home router for wireless in their classroom. The teacher wound up plugging the LAN side into our building network and it was handing out class C's when our addressing is all class A. If this is your problem you can find it without too much pain by doing this: View the ARP cache on the client machine with the bad address and copy the MAC of the default gateway. This is the MAC address of the rogue router. Console into your core switch and view the MAC table looking for the MAC you just wrote down. From here you can see what physical port it learned of the MAC from. View CDP neighbors to see which physical device is connected to that port and then telnet into that device and continue the search. Eventually you come to the last switch inline that has said rogue device jack into it. You should now be able to go to the closet, trace back the patch from the switch port to the patch panel and figure out the physical location. This was done on Cisco hardware, but the principal should apply to other vendor's hardware.

The client is complaining that it hasn't been told where to look for the boot file. It gets this information by setting the options correctly in DHCP. All you have to do is copy what is in options 66, and 67 from the working scope, and recreate them them as server options. Scope options only affect the subnet that scope was create for; where server options will affect all scopes the server hands out addresses for. I've included a PNG of what it basically looks like when viewing the DHCP snap-in. Server options are highlighted and options 66 and 67 need to be defined in this section. Open the scope that has WDS working and get the correct values from there. Don't use mine as my WDS server is extremely customized.

What exactly are your issues? Is PXE booting not working? If not, you need to add the appropriate options to your DHCP server config. Options 66 and 67 need to be set as server options and not scope options so that they will affect every subnet your DHCP server hands out addresses for. Options 66 will be the IP of your WDS server, and option 67 will be the relative path to the boot file. All you probably need to do is move these options from the scope that is working over to server options.

Dell's phone support to me at least has always been next to useless, but you're right; maybe I can convince them to send a main board. The laptop will even power down now when running the Dell Diagnostics. Thanks...

Hey @Cache - No problem! Glad I could help.

I'm at a complete loss for this now. I've got a Dell E5400 Latitude laptop that will randomly shutdown; just like as if the battery were pulled right out from under it. It'll do this on battery or AC power. I'm certain it is not an OS issue as it happened with the original XP load, and now with a fresh Win7 image. MemTest86 comes back error free, and running the CPU wide open for an hour with a burn-in utility does nothing either. The only clue I can find is in the BIOS under Power Events in the System Log section. Every time there is a shutdown an event is logged showing the power down was due to WDT. I know WDT is some kind of watchdog timer, but I can't seem to find anything about it on Google. The system is still under warranty, but I don't know what part to request for replacement. Besides, without an error code or clear cut failure Dell will deny any parts request. Any ideas guys?

Have you tried just resetting the device? Press and hold both the lock and home buttons for five seconds and it'll force power off the device. This should clear the credentials cache. These infernal contraptions are making their way into our district and they've been one headache after another... To make things a little easier on ourselves I setup an Apache server on our proxy to hand out proxy auto configuration files and set address on the iDoohicky. This way if I ever have to make changes I don't need to visit each device again.

I received a request for a copy of a compiled version of the session helper so I'm attaching it to this thread. This is version 1.2 and was compiled on an x86 Ubuntu install. ext_session_acl.zip Be sure to set execute permissions on this file when you place it.

Well, my boot WIM was pulled from an x32 Windows 7 install DVD, so just grabbed the x32 NIC driver for Windows 7 from Dell's site and imported it into the WDS console. Is it still not working for you after doing this?