Mordac85

Unless you saved a copy of the partition BEFORE you started it's Hobson's choice as to what data may be recovered. There are some free utils for this, SavePart and PTedit. It's just a crap shoot otherwise cuz it's like finding what you want in a reference manual w/o the table of contents.

No problem. I had wondered the same thing but just never took the time to track it down. Guess I needed a little nudge.

Yes and no, changing the parition size means you are altering the partition table. Since that is the main table of contents for the data on your drive there is ALWAYS a chance of corrupting it. It's not that the data is actually corrupted, but you are altering the index the filesystem uses to find the data. Partition Magic also comes with utilities to backup your partition table and you MAY be able to restore it if you screw it up. I haven't had the time to actually test that theory, but the concept is sound.

It's in C:\Windows\System32\SYSDM.CPL, Dialog #101. You can edit it with something like Resource Hacker, but just remember that it may get replaced by a future hotfix or service pack.

Welcome to the Blue Screen of Death (BSOD)! The critical information is the stop code (a hex value like the 0xc000005 you have). There may also be a reason listed as INACCESSIBLE_BOOT_DEVICE or a file listed as the source of the problem. Generally, you can google the code or message and track down your problem. It automatically restarts b/c that's XP's default behavior. To stop that so it stays on the BSOD so you can read it, you need to change the behavior (when you can get back into it). Right-click My Computer and go to Properties. On the Advanced tab hit the Settings button under Startup and Recovery. Under the System Failure section ensure the Automatically restart box is NOT checked. Or you can set this registry value: HKLM\SYSTEM\CurrentControlSet\Control\CrashControl\AutoReboot (REG_DWORD) Value=0

Geez, wish I had the time for that. I spent too much time on the board yesterday and am paying for it now. Nice loop tho and you can substitute, or add, any other action to run that against an entire OU. Sweet!

The difference is the amount of information. Unless you know all of the major/minor versions by heart, or want to parse it out, using a script gives much more info. I guess it really depends on how detailed he needs as to what the best/easiest option will be. From his question, I was assuming he was looking for a method to obtain a more detailed result. @Taggs - Do you have an idea of how you want to proceed? If you could tell us what script language you're comfortable with we might be able to toss out a quick code snippet, if you haven't already done so.

I ran into the same problem when I had a caret (^) in my password. I recommend trying jftuga's suggestion to see if it's related to a special character being interpreted as something other than a string character.

If you're running the script on the local system you can use the Kix macros @ProductType and @ProductSuite to get detailed info from Win9x to Vista. Or a WMI query, as mentioned above, in your favorite language to pull the OS name. But I believe systeminfo run against a remote PC will pull from the same WMI namespace.

Sounds like someone doesn't have write perms to one, or all, of those LogonStatus$ shares on your DC's.

I've never come across an error using just the $, but it is sloppy code. As a possible mod to nmX.Memnoch's code, you can also run it from your own system against selected systems in an IP range, domain, etc by throwing it into a loop. Which is probably what you want rather than put another item in your login script that may only hit a subset of your systems. I know if I put a 3rd party util in our NETLOGON share the admins won't pay attention to why it's there and delete it. gotta love the lines of communication!

Actually, it resets after 25 days. So your math will most likely result in a negative numer, not that @TICKS is counting backwards. If you're using Kix on a box w/WMI, there is a User Defined Function (UDF) for pulling the system uptime. The Uptime UDF will allow you to keep from relying on a 3rd party util, if that's a concern for you.

All hail Kix!!! Glad to see it's alive and well here @MSFN. First I'd like to add a few things to the topic. If you don't, or can't, manage to switch to synchronous login script processing through GPO, you can always set the reg key on each machine, but it requires a reboot to start using it. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "RunLogonScriptSync"=dword:00000001 And you can pop up a dialog prior to login with this one: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "LegalNoticeCaption"="WARNING: Use of this System is Restricted and Monitored!" "LegalNoticeText"="Access to this computer system, any of its data, or network resources is limited to those authorized by ..."Kix can also add a CRLF to make the text more legible if your legal eagles get windy. We also add the Help Desk number to the login dialog with this: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "LogonPrompt"="Please call the Help Desk at 800-555-1212 if you need assistance." That's a simple fix well documented on the Kix forums. All you need to do is assign your statement to a variable to eliminate the echo to STDOUT like so: ; Set IE home page $ = WriteValue($IEmain,"Start Page",$IEhome,"REG_SZ") Now, for the slightly OT comments. Kix, while not having a built in engine on Windows as VBScript does, is by far much more flexible. Not only is it much easier to read, its syntax conforms more closely to other languages like Perl and C so it's an easy jump to learn other languages. Also, the support available is much more robust than VBScript. With the addition of COM, WMI, etc there is little you cannot do with Kix while VBS has it's limits. So if you don't want to do much on your login scripts, then VBS and CMD's are great. As for editors, let me just say that Kixstarter is tweaked for Kix and Allan is very responsive to feedback, but I also love UltraEdit Studio now that I can directly connect to my subversion repository.

Unfortunately, we delete the $winnt$.inf file, but I do know nothing is being done to the HAL during sysprep, or afterwards. We can't control the unattended, but I have access to the sysprep portion. I'm working on an alternative now to run a script against a few hundred machines and log the system model and original filename of hal.dll. At least I'll be able to see what is out in the environment now. Looks like I'll need to refresh our images for all the different HAL's. What a pain! Thanks IcemanND for confirming what I already thought would be the case. I also like the idea of the fresh install to see what Windows chooses so I'm adding that to my build process for new hardware. I plan to dump msinfo32 so I know exactly what HW was on my master. Thanks for the idea!

nLite's also a good way to make sure you're not yanking a service that's required for some reason or another. I'd like to understand how to omit some of these useless services too, just not enough time to do so. If you figure it out could you post it? Maybe they could add it to the Guide as well?

Also, be careful that your boot.ini is setup correctly. If you build this system then place the HD in another system, or remove your build drive, you'll crash because the boot.ini will reference a disk that is no longer present. Been there, done that...

You might also want to check your BIOS settings to ensure you're able to boot from the CD before the hard drive. Many manufacturer's are shipping their systems w/the boot order set to floppy first, then the hard drive, and the CD last.

FWIW, An alternative is to use Ghost's GDisk utility. Since I'm creating images as well using Ghost I have the util as part of the package. I have to say that since I started using Ghost, many many moons ago, this one util has made the entire purchase well worth it. It's basically fdisk from the command line. As far as defining this in the unattended routine, I think you're limited if the partition is not already there.

There are 3 keys that I found changed with that setting (there may be others). Since all are REG_BINARY keys, I would recommend running through a normal install, then export the changed settings so you can merge them during your install. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\AcPolicy HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\DcPolicy HKEY_CURRENT_USER\Control Panel\PowerCfg\GlobalPowerPolicy\Policies

I'm not sure this is exactly what you want, but I set the default wallpaper for my Default Users profile by setting HKU\.Default\Control Panel\Desktop\Wallpaper to the location of my pic. Also, the WallpaperStyle key sets Center or Stretch (0 or 2 respectively), and TileWallpaper is self-explanatory. Again, I'm not sure if that's what you were after or if you wanted to define the wallpaper used during setup.

Thanks, that was what I was looking for. From the way it sounds when you reference time T-13 and such I thought it may have been from some kind of documentation I haven't found yet. I don't have anything specific yet but I'm just starting to map out my customizations and when would be the best time to do it. I'll pay more attention to the progress bar and post any additional questions when they come up. Thanks again.

Yeah the site's great and that's how I found MSFN in the first place! But, I have been all through that and the Guide but the closest thing I could find was in the reference section, but I was looking for something more detailed. I see a few references to different time points, T-13 and such, but what exactly are they and what are the rest of them? I was wondering if there was a complete reference to the timeline.

I'm trying to consolidate all of our images and I'm finding that I have very recent systems with the Advanced Configuration and Power Interface (ACPI) PC. My Latitude M60 has that, but we have an image for the D610 that's running the ACPI Uniprocessor PC. I'm afraid the person that created our current image just dropped the old image onto a system, updated it and sysprepped it again. Since we use a highly customized unattended process (not controlled by us) where can I look to see if they have manually set the HAL? Also, can you safely switch between ACPI and ACPI Uniprocessor HALs?

I've been through the Guide and the forums but I can't seem to find a definative timeline for Windows setup. I see references to various points like T-13, T-38, etc and I can piece together the major parts but is the entire timeline available somewhere here or elsewhere?