Jump to content
Compatible Support Forums
Sign in to follow this  
valo

HKEY_USERS hive has 73Mbyte size, probably Exchange issue

Recommended Posts

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

Share this post


Link to post

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

Share this post


Link to post

export the key or backup your whole registry, then deleeeeeeeteeeeeeeeeeee > smile

you can always revert back.

 

Norton Ghost might be a good idea too.

 

(presuming you are able to bring the server down during off-peak).

Share this post


Link to post

Never was an advocate of ghosting servers .....

 

Software raid is unsupported.

Hardware raid (though doable) is unsupported .... DOS drivers are a pain to configure.

 

Besides .... my exchange box has several 10+ gig stores ... I have no intentions to ghost that ....

 

Best way to backup .... Veritas smile Legato smile

Share this post


Link to post

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.

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×