sm5w2

Occasionally I see a pair of entries in the event viewer security log that are attributed to "anonymous user". Event 1: Event ID: 528 User: NTAuthority/anonymous Computer: (name of computer) Source: Security Type: Success Audit Catagory: Logon/Logoff Description: Successful Logon: User Name: (blank) Domain (blank) Login Id: (0x0,0x3639) Logon Type: 3 Logon Process: KSecDD Authentication Process: Microsoft_Authentication_Package_V1_0 Workstation name: (blank) Event 2: Event ID:576 User: NT Authority/anonymous Computer: (name of computer) Source: Security Type: Success Audit Catagory: Privilege Use Description: Special privileges assigned to new logon: User name; (blank) Domain: (blank) Login ID: (0x0,0x3635) Assigned: SechangeNotifyPrivilege They come in pairs, same date and time stamp. the item "0x36nn" seems to change a little, but it's always "0x36nn". The item (blank) is really blank, empty space. The item (name of computer) is the name of the workstation. There is no "anonymous" user in the user manager. System is NT4 server, SP6. Should I be concerned with these items? If not, what are they? Why is their no user name printed? What is the Login ID?

Occasionally I see a pair of entries in the event viewer security log that are attributed to "anonymous user". Event 1: Event ID: 528 User: NTAuthority/anonymous Computer: (name of computer) Source: Security Type: Success Audit Catagory: Logon/Logoff Description: Successful Logon: User Name: (blank) Domain (blank) Login Id: (0x0,0x3639) Logon Type: 3 Logon Process: KSecDD Authentication Process: Microsoft_Authentication_Package_V1_0 Workstation name: (blank) Event 2: Event ID:576 User: NT Authority/anonymous Computer: (name of computer) Source: Security Type: Success Audit Catagory: Privilege Use Description: Special privileges assigned to new logon: User name; (blank) Domain: (blank) Login ID: (0x0,0x3635) Assigned: SechangeNotifyPrivilege They come in pairs, same date and time stamp. the item "0x36nn" seems to change a little, but it's always "0x36nn". The item (blank) is really blank, empty space. The item (name of computer) is the name of the workstation. There is no "anonymous" user in the user manager. System is NT4 server, SP6. Should I be concerned with these items? If not, what are they? Why is their no user name printed? What is the Login ID?

Sorry, should have posted this in another forum...

I've got NT 4 server running on a single-CPU system. It was originally installed on a dual cpu motherboard a few years ago before the drive was moved to a new motherboard. Every time there is a critical update from Microsoft, I have to see if files like NTOSKRNL.EXE has been changed because if the critical update includes a change to (specifically) that file (and possibly a handfull of others) then the system doesn't boot when it's re-started. I have another machine (also running NT4 server) that seems to behave properly (it's also running on a single-cpu motherboard). I check NTOSKRNL.EXE on it to see how it compares to the first machine when necessary. So, my questions are: 1) My machine obviously thinks it's still running as a multi-processor system, to the extent that it will screw itself up when downloading system updates from microsoft that include new versions of ntoskrnl.exe. How do I tell it it's really running as a single-CPU system? Is there a registry setting or two (or a dozen) I need to modify? 2) Maybe I'm not looking in the right place, but when I bring up the properties of files (like ntoskrnl.exe) and select the version tab, all I see is "4.00". Is there no build or extended version number for the various system files that have been released by microsoft for NT4 over the years???? Other than knowing the file time-stamp and file size (and maybe the checksum) is there no way to know the "pedigree" of these updated files??? Am I right about this - that Microsoft has either gotten lazy or sloppy (or just plain negligent) when version-ing these files? Is it asking too much to be able to get build or extended version info for system files?

Originally posted by dosfreak: Quote: Easiest solution (without devoting time to researching fixing this that is) would be to reinstall NT. Unless you can modify setup.log to recognize your system as uni-processor then your SOL since any update that involves the HAL will reference the dual info in your setup.log and reinstall the dual HAL. I've already modified the setup.log to indicate the uni-processor files for hal and ntoskrnl. But I wonder if Microsoft will ever again issue critical updates for NT4 (I think that critical updates for NT4 have just come to an end - yes?) Those 2 files (ntoskrnl and hal) seem to be the only files where there are 2 versions of each - the difference in the names being that there is an "mp" in one version of each. There doesn't seem to be any other files where there are similarly a uni-processor and multi-processor version (at least as indicated in the file name). However, maybe there are uni and multi versions of these files: kernel32.dll NTdll.dll Win32k.sys Winsrv.dll And the only way to tell is by version or build number. Does anyone know if this is the case for those files? Getting back to the setup.log file, I'm not sure how important it is to have the _correct_ hash code (or what-ever the 4/5 digit hex value is) on each line of the file. During a windows-update session, once you've identified the original install state (single or multi cpu) maybe the checksum thingy doesn't play a role. By the way, re-installing NT is basically out of the question since there is software running on it that I no longer have the original source CD (or more like floppy disks). Something else you guys might find interesting: A few years ago this NT4 hard drive was slaved to a computer running Win2k, and then again to a computer running XP. The purpose was to run anti-virus and anti-trojan scans on the drive (seemed like a good idea to remove the drive and slave it to another system, de-frag it while we're at it, etc). Turns out that when you slave an old(er) NTFS file system to a computer running a newer version, the older drive gets modified to the newer NTFS specs. Basically, while NT4 still runs fine when it's put back into the old computer, I can't run tools on it like chkdsk (because it doesn't recognize the NTFS version that it's now running). If anyone knows how to convert an NTFS drive (XP-version) to NTFS (NT-4 sp6a version) let me know. I think this also accounts for why I can't get extended file version info when I look at the properties of files (like ntoskrnl and hal) but when those same files are put on a floppy and brought to a win-2k machine the extended version info can be seen.

Originally posted by sm5w2: Quote: Specifically, what are the most recent versions of those files that have at this point been made available by Micro$oft for NT4 server SP6 for a single CPU (uni-processor) installation (and how do I get checksum info for the ones I have ?). "That's simple enough to find out though! You can extract out MOST service packs with commandline switches... ones like (iirc) /X can send ALL of its files out to a folder you choose, without installing them automatically." I've tried: Microsoft ® File Checksum Integrity Verifier V2.05 and fsum Version 2.51 (http://www.slavasoft.com/fsum/) and I can't generate anything like the codes I see in the setup.log file. Are they checksums? CRC's? How are they generated???

I still wish I had access to a list or inventory or version history of NT4 system files like: kernel32.dll Hal.dll NTdll.dll ntoskrnl.exe Win32k.sys Winsrv.dll Specifically, what are the most recent versions of those files that have at this point been made available by Micro$oft for NT4 server SP6 for a single CPU (uni-processor) installation (and how do I get checksum info for the ones I have ?). Between the 2 machines I have right now, I have a variety of each of those files. I'd like to know why all of them are simply "version 4.00". If anyone knows how to get the build or extended version info out of those files, please let me know (or tell me why that info is not available). It seems that the setup.log file identifies them based on their checksum. One more question - about hal.dll. Is that file generic enough that motherboard makers don't have to make one specifically for individual motherboards - or chipsets?

According to this: http://support.microsoft.com/kb/168132 "The Setup.log (found in the %SystemRoot%\Repair directory) was created when Windows NT was first installed and contains information about the files copied to your system during Windows NT setup. Consequently, the file reflects the information for a single processor computer. When service packs are installed, the Setup.log file is parsed looking for the correct Hal.dll and Ntoskrnl.exe to replace." That is in response to adding CPU's to what was originally a single-CPU system and then running the utility Uptomp.exe from the Windows NT Resource Kit. So basically the culprit responsible for downloading multi-processor kernel updates on my single-processor system is the setup.log file. Now how to modify it so that future microsoft updates are handled correctly? From the above link: RESOLUTION By modifying the %SystemRoot%\Repair\Setup.log file, you can tell the service pack Update.exe program to load the correct multiprocessor components (thus taking you back to multiprocessor support and at the same time ensuring that future service packs install correctly). [in my case, I want to modify it so that it reflects a uni-processor installation] Steps to fix the Setup.log and restore your system to multiprocessors: 1. Remove the read only and hidden attributes on the %SystemRoot%\Repair\Setup.log file. 2. Make a backup copy of the %SystemRoot%\Repair\Setup.log. 3. Open the Setup.log using notepad. 4. Search for and modify the following lines, being careful to use the correct operating system version section and proper HAL for your computer type: Windows NT version 4.0 Modify the entries under [Files.WinNt] section to the following: \<%SystemRoot%>\System32\Ntoskrnl.exe = "NTKRNLMP.EXE","e76ab" \<%SystemRoot%>\System32\Kernel32.dll = "KERNEL32.DLL","5b7f8" \<%SystemRoot%>\System32\Winsrv.dll = "WINSRV.DLL","37b4e" \<%SystemRoot%>\System32\Ntdll.dll = "NTDLL.DLL","59c19" \<%SystemRoot%>\System32\win32k.sys = "WIN32K.SYS","132603" Then, select one of the following HALs and modify the line: \<%SystemRoot%>\System32\hal.dll = "HALSP.DLL","0f337" \<%SystemRoot%>\System32\hal.dll = "HALMPS.DLL","1a01c" Windows NT version 4.0 Terminal Server Edition Modify the entries under [Files.WinNt] section to the following: \<%SystemRoot%>\System32\Ntoskrnl.exe = "NTKRNLMP.EXE","fe754" \<%SystemRoot%>\System32\Kernel32.dll = "KERNEL32.DLL","700ee" \<%SystemRoot%>\System32\Winsrv.dll = "WINSRV.DLL","3e526" \<%SystemRoot%>\System32\Ntdll.dll = "NTDLL.DLL","62b31" \<%SystemRoot%>\System32\win32k.sys = "WIN32K.SYS","140e95" Then select one of the following HALs and modify the line: \<%SystemRoot%>\System32\hal.dll = "HALSP.DLL","15a34" \<%SystemRoot%>\System32\hal.dll = "HALMPS.DLL","1a062" 5. Save the modified Setup.log to the %SystemRoot%\Repair directory. 6. Re-apply the service pack to take you back to MPS support.

Thanks for the info. But answer me this: Will setting registry values (such as # of CPU's) to the appropriate # of CPU's (1 in this case) be the same as if I had installed NT from scratch on a single-CPU motherboard? In other words, do single-CPU systems (installed on motherboards with only ONE cpu) also have a switch in the win.ini and registry where the number of CPU's can be set? I don't simply want to have my NT4 keep thinking it's a dual-CPU setup that's been told to use only 1 CPU. I want it to think, behave, and smell like it's a single CPU setup all the way down to it's very core.

Originally posted by dosfreak: Quote: Where are you checking Product Version at? On Windows 2000... I am talking about a machine running NT 4 server (sp6) not win 2k. All I see in the version tab is "4.00" for system files (like ntoskrnl.exe, hal, etc).

I understand that when an NTFS hard drive from an NT4.0 system is removed and mounted (as a secondary drive) on a Windows 2k/XP system, that some sort of automatic file system conversion is done and the file system on the NT4 drive is converted to NTFS version 3.something. When the drive is re-installed back into the NT computer (NT4.0 SP6) it seems ok with the "new" version of NTFS - although it seems unable to use the built-in drive management tools like scandisk or defrag. I would like to convert the drive back to NTFS 1.x but Partition Magic (version 8.01) does not seem to have that ability. So - how can I convert an NTFS 3.1 drive back to NTFS 1.x (ie back to it's native version) ???

The OS on the drive is NT4 SP6. At various points in the past few years the drive was removed and attached to other computers (running Win2k and XP) in order to perform virus and trojan scans. It was eventually noticed that at some point (presumably after the first time it was slaved to a Win-2K system) some drive maintenance tools were non-functional (ie when you right-click on a logical drive, select properties, tools, check for errors, etc). Norton systemworks 2001 was installed at some point and I believe that those diagnostic and defrag tools also don't run. No, chkdsk doesn't work either. Basically, even though NT works, it seems to know that it's running on a version of NTFS that's foreign to it and refuses to perform any integrity checking or defraging operations. I would like to "revert" it back to it's native version of NTFS. Tell me if this would work: 1) Attach a second physical drive to the computer and start NT4. 2) Have NT format the new drive with the same number of logical drives as drive #1. Presumably NT will format the drive with it's native version of NTFS. 3) shut down the system and boot Norton Ghost from a floppy. 4) in Ghost, perform a partition to partion copy (copy logical drive C: on drive 1 to logical drive c: on drive 2, etc). Would that give me what I want, or will ghost replicate the NTFS version on Drive #1 as it copies it to drive 2?