valo

status: working have exported and deleted the key, everything is working as before. found something else that might have coused this registry entries. SCAN.DAT was not deletable by anybody (even administrator) for about 2 weeks and thus the autoupdate failed (manual update worked with different filename for dat file). after a filesystem check and manual deletion of the SCAN.DAT file autoupdate is working again and registry size has not changed anymore. no problems anymore, but i still dont know why there have been that much registry entries, i still think the autoupdate failures have caused them. autoupdate said update is not possible but it did'nt mention that the file was not accessible.

Problem has status: ??? (can't reboot server before 6pm) I logged on to the user the Exchangeserver is running and exported the "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profile" and then deleted this key and reimported an edited copy (deleted all "ExchangeAdmin" entry's and only left one) of the exported file. Everything seems to work well, but i still don't know what program created that much key's in the registry. Probably it's a part of the Groupshield software. Groupshield and Exchange services are startet using the same, none systen user. Maybe these entry's have something to do with a failed Groupshield Autoupdate and are only temporary entrys to the registry and not deleted in case the updateservice fails/crashes (have to search events from the last few month's to verify how often autoupdate failed). update will follow

Hi! I have previously searched MS KB, Technet, Google and Google Groups and some Exchange Forums on the Net without getting a result that would help. We have an Exchange Server 5.5 SP4 with GroupShieldExchange 4.5.572.128 running on Windows NT Server 4 SP6a for some years now. The problem is, GroupShield Exchange filters out any attachment on external and internal email, possibly because the Userpart of the Registry of the user the Exchangeserver is running is about 73Mbyte in size and gets loaded into memory resulting in an actual Registry size of about 82Mbyte. This mass of data is located in HKEY_USERS\[sID of USER running Exchange]\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles where there are Keys like these examples (NT-GDF is the servername): Exchange Nailgun Admin NT-GDF 0x0001cb 00000000 ExchangeAdmin NT-GDF 0x047839 <about 17.000 more "ExchangeAdmin" keys with different hexadecimal value appended> ExchangeDS NT-GDF 0x0667b3 Temp NAI {some date in the past} (about 20 of that type, seem to be from Groupshield) These ExchangeAdmin keys seem to be configuration data but i'm not really sure what they really are and do so i don't want to delete them without knowing what they are. We have a second Exchange Server with same Servicepack/Groupshield/underlying OS that does not have this problem at all. The difference between these two Servers is that the one having this problem is connected to the other one via the "Site connector" and mail is routed to the server having no problems. Thanks in advance valo lindstroem

thanks duhmez, but it's not possible for me to add a user from any domain to a global group, but it is possible to add a user from any domain to a local group. the problem now is, the filesystem permissions are set up with global groups and it's not possible to add a group to a global group. i think i have to make a new group and add this group to the filesystem permissions... thats much much work to do... :-/

you should edit the file c:\boot.ini as well to inform the bootloader what disk to access for booting...

hi! is it possible to convert a nt4 global group to a local group without deleting the global group and adding a new local group? we have 2 domains in our organization that trust each other. now someone from domain 1 needs to access files on the fileserver in domain 2 where this guy worked before moving to the other building. most of the groups are "global groups" and it's not possible to add someone to a global group having no account in that domain but it is possible to do that with local groups. adding a new local group in domain 2 and adding this group to the filesystem acl's would be the last thing i wan't to do because its really much work to do valo