1 Reply Latest reply on Feb 14, 2013 10:59 AM by tstidham

    Changing Unmanaged Utility Jobs


      Sorry if this is in the wrong place or the question has been asked before (though I don't think it has as I've spent the past hour searching on the internet in general, and here on thwack).


      We have one job created using the Scheduled Unmanage Utility. We had already discovered this utilities asinine habit of locking the jobs to the user that created it, so we made a specific servername/local_admin account for scheduling jobs. Now, however, solarwinds tells me this account does not have manage rights. The password has not changed, it's in the same groups it's always been in and no one but me has been on the server or inside this utility for the past 6 months (which was the last time I needed to change unmanaged servers). I am beyond frustrated at this point trying to edit the job. My other admin accounts can log into the utility, but can not open the job and the job owner can't log into the utility. Any help/suggestions/bullet to the head would be appreciated on this. There are many servers and times in this single job and if there is no way to edit it or switch ownership, then I'll simply leave it be and let the rest of IT know they can only do things within the current windows (because I'm definitely not recreating the job).

        • Re: Changing Unmanaged Utility Jobs

          Ok, I figured out I can edit the XML file and remove the following line from the top of the file.


          <SwisConnectInfo Server="ServerName" ServerType="Orion" UserName="ServerName\UserName" Password="nyUvci0ua5awDQTy8LKdPg==" />


          The password field is a hash of some sort of the original password, but by removing this line from the XML, then any user that can log into the Schedule Unmanage Utility can open that job without error. When saved, it puts the above line back into the XML file using the current users credentials. I guess I'll have to try and recreate the global local admin account and hope solarwinds doesn't drop its "manage permissions" again.