OpsMgr Caching Bugs?

OpsMgr Caching Bugs?

Home » Operations Manager » OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 5:33 AM :: Rank: 62

Author

Andreas Zuckerhut

Points: 27584
Level: System Center Expert

First of all, the whole caching in Operations Manager is fscking annoying and really a pain in the a** when developing MPs.

Situation 1 - Displaynames: So, I have a custom Management Pack in XML where I created a group called "CG Coregroup", a Subgroup as member of it called "CG Coregroup.SubGroup".

I didn't want the dot in there so I changed the MP so it is "CG Coregroup Subgroup" but, in the console it still said "CG Coregroup.Subgroup". Opened the Group, there it stands correctly without the dot.

So I wasn't sure if the Name displayed in the Group Window directly affects the Name in the list. Changed it there, voila, works.

So, I deleted the Management Pack, changed the version, no matter what I throw at it it still doesn't update the Name in the list. The huge problem here is that I have nested groups which target the displayname which is cached somewhere wrong and therefore it doesn't work.

Sure, I can manually re-apply the name for every group but this is just not acceptable.

Situation 2 - Scripts

The best thing I stepped over so far was when I was developing a script within a Management Pack. It somehow used the old script when I didn't change the version before reimporting. I think it was even sealed. It wasn't a one-time thing, it happened over and over again.

Report Abuse

RE: OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 10:22 AM :: Rank: 84

Author

Pete Zerger

Points: 65502
Level: System Center Expert

I agree, and have a couple of thoughts. Let me know how these align with your experience.

Situation 1 - Caching

On the caching item, I close and re-launch the Ops Console with the /clearcache flag. Have you tried this?

Situation 2 - Old Scripts

On the 'using an old script', have you verified that the new MP has been recieved (event 1201 in the Ops Mgr Event Log) and workflows loaded (event 1210 in the Ops Mgr Event Log) on the affected system?

I see previous versions of my scripts running during the authoring process all the time, but it is usually because the new version of the MP has not yet loaded.

Report Abuse

RE: OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 10:53 AM :: Rank: 86

Author

Andreas Zuckerhut

Points: 27584
Level: System Center Expert

Hi,

thanks for your reply.

1 - I just tried it with /clearcache but that doesn't solve the problem at all. Maybe my first post was a bit confusing, so again:

This is my problem PICTURE - The name is already updated but as you can see in the top the dot is still in there, therefore somewhere inside OpsMgr it still uses the old name. Once I reapply from within that window it's fixed.

To evade that I tried:

- Deleting the Management Pack before importing it again

- Deleting the Groups manually before deleting and importing it again.

- /clearcache switch

- Changing the Version of the Management Pack

The problem is that I can't accept it this way due to the fact that soon I will import around 50 Management Packs which contain 50 Coregroups, around 100 Subgroups and maybe 20 SubSubgroups.

If I have to change the naming convention for some reason I won't click apply for a few hundred groups just because OpsMgr uses old DB or Cache-Entries.

2 - I'd have to reproduce the error to verify that, but as far as I remember I always checked that, especially because of scripterrors which happened right after the import.

Report Abuse

RE: OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 11:00 AM :: Rank: 76

Author

Tommy Gunn

Points: 42718
Level: System Center Expert

That is odd, and nothing that the /clearcache mentioned would actually fix in this case I don't believe. When I get into the lab this afternoon, I will try to duplicate and report my results. Looks like a possible UI bug to me.

Report Abuse

Re: OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 1:14 PM :: Rank: 84

Author

Simon Skinner

Points: 40744
Level: System Center Expert

Question, how do we know that the clients in fact are not caching data. We have seen this with Group Policy before can Ops Mgr clients do the same. The MS only report what the client report.

Report Abuse

RE: OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 4:49 PM :: Rank: 80

Author

Marius Sutara

Points: 545
Level: System Center Hero

for 2 - old script executed:

with sealed MP and not changing (increasing) version, we do not see the need to download MP to the agent. Unsealed MP is sent down every time.

Report Abuse

Re: OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 4:55 PM :: Rank: 60

Author

Davidstclair

Points: 2605
Level: System Center Specialist

I've seen this a few times where the agent doesn't update, and the agent cache has to get cleared manaully. Recently I've run in to this a lot with R2 agents on Server 2000sp4 machines.

Report Abuse

Re: OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 7:56 PM :: Rank: 66

Author

Tim McColl

Points: 180
Level: System Center Hero

I've seen this change group name behaviour in OpsMgr 2007 SP1 and R2 RC systems. The following is a simple test MP. Import the MP and there should be a group named CS Test AppName Group. Then change the name of the group in the MP and re-import. The name of the group will not change. Even deleting the MP from OpsMgr and importing will not rename the group

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>Computershare.Test.AppName</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>Computershare.Test.AppName</Name>
    <References>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
</Manifest>
<TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="Computershare.Test.AppName.Application" Accessibility="Internal" Abstract="false" Base="System!System.Service" Hosted="false" Singleton="true" />
        <ClassType ID="Computershare.Test.AppName.Group" Accessibility="Internal" Abstract="false" Base="System!System.Group" Hosted="false" Singleton="true" />
      </ClassTypes>
    </EntityTypes>
</TypeDefinitions>
<LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Computershare.Test.AppName">
          <Name>Computershare Test AppName</Name>
          <Description>Test whether a System.Service "application" singleton can be renamed.</Description>
        </DisplayString>
      <DisplayString ElementID="Computershare.Test.AppName.Application">
          <Name>CS Test AppName</Name>
          
          <Description>First import of MP object has name "CS Test AppName". Second import name is changed to "Computershare Test AppName"</Description>
        </DisplayString>
        <DisplayString ElementID="Computershare.Test.AppName.Group">
          <Name>CS Test AppName Group</Name>
          
          <Description>First import of MP object has name "CS Test AppName Group". Second import name is changed to "Computershare Test AppName Group"</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
</LanguagePacks>
</ManagementPack>.

Report Abuse

RE: OpsMgr Caching Bugs?

Posted: Wed, Jul 08, 2009 11:15 PM :: Rank: 71

Author

Marius Sutara

Points: 545
Level: System Center Hero

I think I remember something I learned quiet some time. If group is a singleton, its name contributes to how its instance ID is calculated (we always caclulate instance ID for every "monitoringobject"). If name is changed, I believe we only reflect this in display name, but we need to keep original name in order to avoid group re-population, instance space integrity etc ...

I do not own this are so I would need to code review/investigate to confirm. But I surely hope I'm correct ...

Report Abuse

RE: OpsMgr Caching Bugs?

Posted: Thu, Jul 09, 2009 4:27 AM :: Rank: 80

Author

Andreas Zuckerhut

Points: 27584
Level: System Center Expert

Yea, Tim McColl has reproduced it there perfectly.

I'm using Singleton Classes too, the problem is that it's not just a cosmetical problem, it's also a functional problem since I nest the groups against the Displaynames, and the Displaynames don't seem to be changing since the nesting doesn't work until I reapply. Of course I could change the targeting but that still doesn't solve the problem.

The funny thing is however, the Singleton Class condition may be true, but why does it all change once I manually reapply the Name?

And, also in the Authoring Pane under Groups it shows the old name (I guess this view doesn't use the Displayname Property then?)

And, why does OpsMgr not delete a Group when I tell it to. Same goes for Management Packs. When I delete something I want to get rid of it and don't want to have it cached somewhere in the background because it could be used the same way again ^^

If I have many changes to the names in the production environment, it will turn into quite a mess and I don't see the advantages of this concept.

Report Abuse

RE: OpsMgr Caching Bugs?

Posted: Mon, Aug 10, 2009 7:09 AM :: Rank: 70

Author

Andreas Zuckerhut

Points: 27584
Level: System Center Expert

I just came across another problem. I have a Management Pack with a few monitors, one of these monitors launches a script that checks for service state like: Service name, desired state, desired startup mode.

I have entered a wrong servicename at first which caused a wrong state since the service doesn't exist. However, I fixed the servicename, reimportet the management pack and voila: it still uses the old servicename.

Fix: Remove Management Pack. Import it again. Versioning doesn't change anything.

I have had this problem earlier already where a Management Pack uses an old version of the script.

Report Abuse

RE: OpsMgr Caching Bugs?

Posted: Mon, Aug 10, 2009 10:05 AM :: Rank: 80

Author

Pete Zerger

Points: 65502
Level: System Center Expert

In the OpsMgr Event Log you've verified the 1201 and 1210 events on that agent-managed computer verifying it has received the updated version?

It would be interesting to check the xml on these systems in the \health service state\management packs\ subdirectory to see if the new version of the script appears in the file.

With unsealed MPs, agents should pull down updated MP even if there is no version number change.