5 Replies Latest reply on Dec 19, 2015 12:16 PM by Charlie Sullivan

    Windows Server Fails Patch Analysis

    Charlie Sullivan

      I have one Windows server that is failing a patch analysis in a way that I haven't seen before. I get something similar to this in the log from the analysis job each time I run it:


      Error while running pre-analysis on server: server-a, Error: Failed to create agent side analysis directory: //server-a/C/Program Files/BMC Software/BladeLogic/RSCD/tmp/WindowsCatalog_2099338_172_server-a

      (Caused By: JNI fileExists '//server-a/C/Program Files/BMC Software/BladeLogic/RSCD/tmp/WindowsCatalog_2099338_172_server-a' failed:: Connection timed out)


      I've checked the RSCD log and there is no entry for the time of the analysis failure. As a troubleshooting measure I temporarily added the RSCD Agent account to the Administrators group, which of course made no difference. I also confirmed that an Administrator can write to the tmp directory in the above path.


      I'm not sure what else to look at. I've searched for similar issues in the Forum but it seems that I didn't find anything that was exactly the same. I don't know why we get "Connection timed out". I am able to live browse the file system, registry, etc. Not long ago I successfully upgraded the Agent to along with hundreds of other Windows servers.


      Thanks in advance for any help.

        • 1. Re: Windows Server Fails Patch Analysis
          Davorin Stevanovic

          to what local account you are mapping your role/user, you can check this in export,users,users.local files and check if that user is in Administrator group.

          • 2. Re: Windows Server Fails Patch Analysis
            Yanick Girouard

            The answer is in the error message: Connection timed out


            This means the app server was unable to reach the agent at the time of the job run. This could be due to the one of the following:


            - Network timeout

            - The agent is unable to answer the request due to high cpu usage on the remote server. I have seen cases where a server would give this error in BladeLogic because its CPU was used at 100% by another application. The RSCD agent runs with a normal processor affinity so if someone else takes all the juice, it won't be able to answer and it's normal.


            This is why you don't see anything in the agent's log, it never gets there to begin with.

            • 3. Re: Windows Server Fails Patch Analysis
              Charlie Sullivan

              Thanks for the replies.

              I finally discovered the issue:

              This particular server is behind it's own firewall. I knew that the firewall was allowing connections over 4750 from the "main" BLAPP server. However, there are 4 different BLAPP server instances which the BL Administrator had set up. Whenever I ran the analysis job, it was using one of the other instances, thus not coming from the "main" BLAPP server. Once I created a new analysis job, specifying the server to be the "main" BLAPP, the job succeeded. This explains why I could do things such as live browse without issue, which threw me off.


              I'm not sure I'm making sense with my terminology of "server instances" and "main" BLAPP because I'm not the BLAPP Administrator. Each BLAPP instance apparently has it's own IP address, thus the firewall deny when the job isn't coming from the "main" one.

              • 4. Re: Windows Server Fails Patch Analysis
                Bill Robinson

                "Once I created a new analysis job, specifying the server to be the "main" BLAPP, the job succeeded."

                -> so you setup a job routing rule for this job to run from the 'main' appserver ?


                you need to make sure all appservers can connect to all targets on 4750, otherwise you defeat the purpose of having multiple appservers.

                • 5. Re: Windows Server Fails Patch Analysis
                  Charlie Sullivan

                  Thanks for the reply.


                  This is the only server out of about 300 Windows servers for which we need to use this workaround. All of the others are reachable over 4750 from all of the blapp servers.


                  This is an oddball machine which is not in our data center (like all of our other servers). Because of this it's behind its own Pix firewall and nobody seems to have had responsibility for maintaining the FW rules since they were set originally. So once I discovered what the problem was, I realized it was easier to do this workaround than to try and chase down the person responsible for the FW.