6 Replies Latest reply on Mar 20, 2012 12:07 AM by Ryan Koziel

    Utility updateServersStatus issue

      Working on a NSH script to update the server status (Utility updateServersStatus mimicks the "verify" functionality found in the console). The commands used in the script are below. To summarize the problem:

       

      1) Verify that the servers using verify in the console. The AGENT_STATUS is set to "agent is alive".

      2) Ensure the servers in question are licensed via agentinfo.

      3) Execute the NSH commands to run updateServersStatus. The script returns in just a few seconds (less than the 60 set for timeout on the updateServersStatus command) with the message "Could not update all properties for 'statp51' because the agent is not responding. Only the AGENT_STATUS property was updated." for all machines in the group.

      4) The AGENT_STATUS on the target machines is set to "agent is not responding". However, the agent is running, I am able to execute jobs against the machines, and doing a verify again puts the status back to "agent is alive".

       

      BladeLogic 8.2 GA (8.2.0.158) and the target machines in questions are RHEL 64-bit. The 8.2 agent is installed on the target machines and is running w/o issue.

       

      SCRIPT

       

      SERVERGROUP="/By Role/Stats Servers/Production"

      blcli_execute Server listServersInGroup "$SERVERGROUP"

      blcli_storeenv SERVERLIST

      FMT_SERVERLIST=`echo $SERVERLIST | sed -E 's/[ ]/,/g'`          # Make the list comma-delimited for input to Utility updateServersStatus.

       

      blcli_execute Utility updateServersStatus $FMT_SERVERLIST 10 60000 true

       

      OUTPUT

       

      voidCould not update all properties for 'statp51' because the agent is not responding. Only the AGENT_STATUS property was updated.

      Could not update all properties for 'statp52' because the agent is not responding. Only the AGENT_STATUS property was updated.

       

      Update 3/15

      I removed the line where I am formatting the server list to include the commas and just hard-coded 1 server (with the comma) for testing. This time I am using a windows server as the target machine.

       

      I did the same as above: verify server, ensure it's licensed and the current AGENT_STATUS is alive. I execute the script and I get the same message about the agent not responding.

       

      SERVERLIST="odcsgacpxoe02,"

      RYAN-W7# blcli_execute Utility updateServersStatus $SERVERLIST 10 60000 true

      voidCould not update all properties for 'odcsgacpxoe02' because the agent is not

      responding. Only the AGENT_STATUS property was updated.

       

      The rscd.log on the target machine contains the following. Logs shows nothing in regards to the agent not responding.

       

      03/15/12 14:08:34.577 INFO     rscd -  ODCSGACPXOE02 4272 SYSTEM (Not_available): (Not_available): Adding account right "SeDenyInteractiveLogonRight" to user BladeLogicRSCD@ODCSGACPXOE02 for user privilege mapping

      03/15/12 14:08:34.878 INFO     rscd -  10.28.64.119 4272 BladeLogicRSCD@ODCSGACPXOE02->Anonymous:PrivilegeMapped (root): agentinfo: agentinfo odcsgacpxoe02

      03/15/12 14:08:34.883 INFO     rscd -  ODCSGACPXOE02 4272 BladeLogicRSCD (Not_available): (Not_available): The operation completed successfully. 

      03/15/12 14:08:46.188 INFO1    rscd -  10.28.64.119 3840 svc_bladmin@DEVCS:PasswordLogon (BLAdmins:RYAN@WORKDOMAIN.COM): CM: > [Client] Retrieving property values

      03/15/12 14:08:46.192 INFO     rscd -  ODCSGACPXOE02 3840 svc_BLAdmin (Not_available): (Not_available): The operation completed successfully. 

      03/15/12 14:08:47.239 INFO     rscd -  ODCSGACPXOE02 3840 svc_BLAdmin (Not_available): (Not_available): The operation completed successfully. 

      03/15/12 14:08:47.242 INFO     rscd -  ODCSGACPXOE02 3840 svc_BLAdmin (Not_available): (Not_available): The operation completed successfully.

       

      The target machine's RSCD agent is still running. The agent status is now "agent not responding", but when I do a verify the agent status goes back to alive.

       

      There is a ~12 second gap between where things are running as the local user BladeLogicRSCD @ 14:08:34.883 and what may be the change to the automation principal svc_bladmin@DEVCS. Since I am sending in 'true' to the updateServersStatus command, the 'request' goes through the application server and there is an automation principal set on the role being used, would that be contributing to the issue?

       

      Anyone have any ideas? Am I hitting some sort of bug here?

       

      UPDATE 3/19

       

      If I use NSH directly on the application server using the exact same commands and targets (app server is RHEL 5.5), the command runs w/o issue. I am only experiencing the problem when I run NSH locally (Win 7 x64).

       

      Message was edited by: Ryan Add more info.

        • 1. Utility updateServersStatus issue
          Bill Robinson

          why don't you use the "Update Server Properties" Job type?  it does the same thing.

          1 of 1 people found this helpful
          • 2. Utility updateServersStatus issue

            That is what I did originally actually, Bill. Let me elaborate on what I am trying to do:

             

            We are on 8.1 GA but working on upgrading to 8.2. I originally had a batch job containing a deploy job for the installer followed by an update server properties job. The idea being that we upgrade the target and then ensure the properties for the RSCD agent were updated too so that smart groups & reports didn't show the target as having the older RSCD version. The problem was that the update server properties job didn't updated any of the properties related to the RSCD version (RSCD_VERSION, AGENT_MAJOR_VERSION, etc). I tried running the update server properties job outside of the batch job with the same result: properties weren't updated. The only way I could get those properties updated was to do a verify on the target...hence why I am trying to write a NSH script to execute that command against the target machines (idea is to include that as part of the batch job).

             

            So, is that the issue then? The fact that the update server properties job isn't updating the RSCD version properties?

            • 3. Utility updateServersStatus issue
              Bill Robinson

              so right now, what is 8.1 and what is 8.2 in your env?

              • 4. Utility updateServersStatus issue

                The following are 8.2
                - Application Server

                - Console

                 

                The following are 8.1

                - Various targets connected to this blade environment.

                • 5. Re: Utility updateServersStatus issue
                  Bill Robinson

                  Was there an error from the USP?  Or just nothing?  What’s in the job run logs for the usp ?

                  • 6. Re: Utility updateServersStatus issue

                    I received the below from the USP job each time I ran it. just showing the latest:

                     

                    JOB RUN

                    Info Mar 19, 2012 10:47:44 PM The job 'Update server properties' has succeeded

                    Info Mar 19, 2012 10:47:39 PM Executing work item Update Server Properties Job:Update server properties; Server:osi07;  on application server: blgdev01

                    Info Mar 19, 2012 10:47:38 PM Started running the job 'Update server properties' with priority 'NORMAL' on application server 'blgdev01'(1)

                     

                    TARGET EVENTS

                    Info Mar 19, 2012 10:47:44 PM Succeeded

                    Info Mar 19, 2012 10:47:44 PM Updating Agent Status... Updating Server Properties... Updating Configuration Objects Registration

                     

                    But, I was unable to reproduce what I said above with the properties not updating. I thought I had it a few times but in all cases it was just a matter of waiting and making sure to refresh the group and not just flip between servers. I won't go into the nitty gritty other than to say I didn't have things setup per BMC recommendationshere.

                     

                    But since I have successfully polluted the original intent of this post, I am going to table the issue as I can run it from the app server and the USP works as long as the job does.