cluberti

Since adding sites to a security zone is just a registry setting, why not make sure these are in the default user hive?

At least since Windows 2000, everything internally is done in GMT (UTC) and the offset of file times and the clock is simply a display issue - the OS inside is doing everything on UTC. A system that is configured in a time zone that experiences DST will change the clock display at 2AM on the requisite day and the internal bias for local time will update, either forward or back as necessary. That would be more a behavior of the app itself (and what APIs it uses, if any, to determine the correct UTC offset) rather than Windows - I'll explain further on. That depends on what API was used to request system time. If, say, a C or C++ app was to call time, it would get the current offset from January 1, 1970, not an actual time. Hence it would have to make a determination what GMT offset the system was at, etc - it would not be given by time. In Win32, there is no API to give you all of the data you want, but you could create a SYSTEMTIME structure, get SystemTimeToFileTime, copy FILETIME to a large INT, and then do arithmetic on the value (not pretty). There are other combinations of APIs that can be used in tandem to determine the system (UTC) time, the current time zone and time zone offset, and then determine whether you're in DST or not:GetSystemTime - current UTC time GetLocalTime - current local time GetTimeZoneInformation (2003, XP, 2000) / GetDynamicTimeZoneInformation (Vista+) - gets the current time zone info, including whether or not DST is currently in effect You would then use the data you returned to determine what the actual GMT time is, etc. As you can see, it's not something you just "get" when you're running on Windows as an app - you have to query it (properly) and manipulate the data you get back to determine this sort of data. Any shortcuts in getting the info, or failing to deal with the data returned by GetTimeZoneInformation to determine if you're biased due to DST, etc, will result in the wrong time used in an app. It's not hard to do this, but it's not easy either, and I too have seen any number of apps that screw it up.

If it runs, and you cannot see it, is it possible the window is simply off-screen? Does it appear when you're running in safe mode or VGA mode?

Moved to XP - not sure this is specifically a WinPE issue, so moving to XP.

http://www.msfn.org/board/forum/147-windows-updates-downloader/

If you slipstream the Vista network driver into the boot WinPE you're hosting on the WDS server, it should use that rather than an inbox OEM driver.

It's not a hardware error. I would start with a clean Windows ISO and install, and if that works start doing things step by step - add drivers, rebuild, test; add apps, rebuild, test; etc. until your build fails.

If you are running /generalize, then yes it is - there are functions that run on a generalized image when the hardware has changed if /generalize was specified when the machine was sysprep'ed.

Usually when djoin exits out with error code 0, it really is an error code 2138, or 0x85a (the exit code of 0 is the last error code, which would be 1 if it worked). 0x85a is generally an error setting or resetting a machine account in the domain, but if you're using the same user/pass combo in both answer files (might want to check for typos, trailing spaces, etc just in case) it doesn't make a whole lot of sense why it's failing only on x64. Note that WDS has it's own set of rules for this, where the account set/reset is done with the creds entered into the WDS UI once you've booted PE (before you see the images), although the error is likely the same error code.

0x3 in the log in this location likely is "ERROR_PATH_NOT_FOUND", meaning the file got deleted during sysprep, but for some odd reason sysprep is going back and trying to touch the file or it's registry. Does the SoundMax package install any drivers or services that are running on the system after the installation? It would indicate that the sysprep (for whatever reason) wasn't able to cleanly remove the driver, or information about it, during reseal. Not sure why it's specific to a particular image, but once this happens that image is pretty much toast - you'll have to rebuild. Once you've sealed it and the problem is in place, you aren't going to get out of that loop.

0x8E means KERNEL_MODE_EXCEPTION_NOT_HANDLED, and the second param (0xc0000005) means it was a memory access violation. How was this unattended install created? What was slipstreamed (drivers, apps)? What features were removed? Etc.

If it happens from all clients, then that would mean that the server has lost it's trust relationship, and you'll have to remove/re-add to the domain. What's probably worth looking into is WHY the server's trust was broken - did it not update with a DC for an extended period of time and have it's computer account tombstoned? Did someone create a new machine with the same name and add it to the domain, overwriting the server's computer account info (and thus invalidating it)? Etc...

If you want a pre-made tool, there are lots of them out there (just use the internet and search). If you're talking about using something like a script or an HTA to do this, those exist as well (again, search the 'net - they're out there). Creating user accounts from a template using a script or HTA is not difficult, and there are full-blown Win32 and MMC apps as well (some free, most not) that can do this as well.

Moved from W2K to Networking. As to the questions of L2 vs L3, it would depend on the vendor and their implementation of L3 (and managed vs unmanaged). For example, some Netgear switches are considered "smart" switches, and aren't truly L3 complete (even though they try to advertise it as such). Most of the benefits of a managed L3 switch come with things like multicast, VLANs and tagging, QoS for protocols, streaming media, etc - you'll see benefits there if you want to configure your switches to handle those types of traffic specifically. If you're looking for just a "dumb" network that routes packets based on MAC address and you aren't going to do any QoS, multicast, or VLANs, you probably don't need an L3 switch (yes, you can do some of these things on an L2 switch, but not very well comparatively). Again, for such a small network, an L3 switch might be overkill, but if you do plan on doing a bit of media streaming, or multicast transfers, or even VoIP, an L3 switch with proper QoS support will help that network out quite a bit.

#1 - http://www.msfn.org/...plorerexe-view/ #2 - lusrmgr.msc Note that explorer views (#1) are per user, so you'll need to make sure that each user gets these applied on login, or make it a part of a default profile in your netlogon share that domain users will pick up.

Further discussions of warez will result in a ban. Please don't use warez software, and note that the 30 day *grace period* from install to entering a key is not meant to be a "trial" as people claim. The only trial versions of Windows are server versions and Win7 Enterprise (an actual, expiring trial), and are available from microsoft.com directly.

You could also use CTRL+ALT+DEL to open taskmanager to see if explorer.exe is running - if not, the default shell in the registry probably was damaged by the malware and no longer points to the correct binaries. I believe it's HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell, and Shell should be explorer.exe, and Userinit should be userinit.exe.

That works around it (and it still exists in Vista and Win7), but it won't help you find the culprit causing the calls to reset the session lock timer. If all you want to do is remove the symptom, sure, but if you want to troubleshoot (there are ways to hook calls and catch them to see who's doing it) this wouldn't be recommended.

You might want to be careful of clicking the "Accept" button on software then, because it was displayed to you when you installed nLite. Glad to see you've found a solution, but again, be careful of warez. You'll find MSFN very intolerant of warez discussions (not necessarily warez users, but discussions of it here).

First, welcome to the forums . Second, bolding sections of your post is equivalent to using all caps, aka "shouting". Please remember forum etiquette when posting, and only "shout" when necessary. Thank you.

Honestly, my guess is the path - <Path>\\driver</Path>?? If you press Shift+F10 to get a cmd prompt, can you net use \\driver? I would guess no, because that's a server name - where's the share name?

Removal of the two additions bring it back? I'm not sure how DOSBox would cause anything (or installation of anything in DOSBox for that matter), but if you know what changes were made since it worked rolling them back would be a start. Anything that would hook DirectX and the display could cause it though if it keeps grabbing any portion of the display (it will reset the idle timer).

Booting an entire OS inside a VHD from a parent OS requires the OS inside the VHD to also have a bootloader which is capable of doing the boot translation when inside of a VHD, which is currently something only 2008 R2 and Win7 can do natively, and something that can be done *ON* Server 2008 and Vista by replacing it's bootloader with one from Win7 (meaning Server 2008 or Vista can host an OS booting from VHD, but cannot actually boot from VHD themselves). Neither Server 2008/Vista nor XP/2003 can actually be an OS booting from within a VHD due to these OSes lacking any support for a VHD bootloader, and as such you cannot boot Server 2008/Vista or older from within a VHD.

You have to remember that the bootmgr code is expecting to boot from either local media or WDS - it's not designed with anything else in mind, so you may be hitting all kinds of problems when you change up the underlying infrastructure, no matter how closely it portends to emulate the native environment (in this case, WDS) that WinPE would boot from.

http://www.msfn.org/board/topic/140247-trace-windows-7-bootshutdownhibernatestandbyresume-issues/