Ah, but I *am* paranoid - I don't trust computers at all, they're rubbish. Its actually got stranger. While that appeared to fix the problem - the RM current information often goes AWOL - unless you stop and start the IMA Service (or reboot the server ;) ) - then it (RM current information) comes back but doesn't update. Looks as if each IMA Service is not correctly getting its own RM information - so the summary server doesn't stand a chance as the summary info is goosed. Still - I've discounted *another* thing it could have been - there can't be that many more right :p From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Rick Mack Sent: 09 May 2008 05:12 To: thin@xxxxxxxxxxxxx Subject: [THIN] Re: Memory optimisation conflicting with Resource Manager Hi Andrew, ADSclean is unnecessary, as is a reboot. The memory optimization works in 3 phases: 1. monitor operating system rebasing of DLLs to discover an optimized memory address for a DLL. This can take a while depending on the frequency of use of the DLL. 2. permanently rebase a copy of the DLL by a binary moficiation of the jump tables and link the modified DLL to the original copy as an alternate data stream (ADS). 3. hook the load library routine so that when a DLL has an ADS copy, load the rebased ADS copy instead. step 3 is carried out by the memory optimization service which uses an registry based exclusion list of executables and DLLs that determine whether an ADS copy of the DLL will be loaded or not. ADS DLL loads are stopped immediately when you stop memeory optimization on a per-server or per-farm basis. Executable exclusion lists are handled via the management console and distributed to all farm servers. DLL exclusion lists require a server-based registry hack and a modified reg file or scripted registry update has to be distributed on a per-server basis. Citrix donot propagate DLL exclusions, you do. That's a really long roundabout way of telling you that you don't have to run ADSclean unless you're paranoid or short on disk space, and a server reboot is totally unnecessary :-) But ADSclean is useful for finding out what has been rebased. RM performance data collection is one of the things done by the IMA service via the RM*.dll modules but since IMASRV.EXE is one of the default excluded executables, any DLL component of imasrv.exe would also be excluded. IN any event if all the servers did stop recording RM information at around the same I'd be tempted to suggest that the problem might be on the RM summary server. regards, Rick -- Ulrich Mack Quest Software Provision Networks Division On 5/7/08, Andrew Wood <andrew.wood@xxxxxxxxxxxxxxxx> wrote: Hi, I've had a customer come with an odd problem - they use RM for billing; but April's report appeared broken - only some information was available. Investigating the issue showed that the summary information wasn't being recorded correctly in the databases - despite the server RM logs saying everything was working fine. All the servers stopped recording information about the same time. What was very strange is that looking at the presentation server console showed that local database and summary database information wasn't available - just blank information - no users, no processes - only the server names. Everything appeared in order, but no data was accessible. I saw that Memory Optimisation was enabled - so I took one of their servers, excluded it from memory optimisation and ran adsclean 2. Then I rebooted it. When the server came back - I could look at user information, and a after running a summary update - I could see billing information again. No one knows, by any chance, what processes run to gather/display the RM information so I can test excluding it - at the moment I'm working on all .dll files beginning with RM Tia. a. Andrew Gilwood CS Ltd Registered Office : Mount Ashbrooke, Holmland Buildings, Tunstall Road, Sunderland, UK, SR2 7RR. No. 6099397 England