Hi,
This is not for a customer, it's a phenomenon I'm seeing in a VMWare test lab on a regular basis (at least 3 times a week). The ONLY way that seems to fix this is to do the following in sequence:
- Go into Designer on the database server or admin workstation NOT on any other job server:
- Edit the job service configurations for every job server
- Refresh the account details for EVERY job server in turn
- Export each configs to file
- Commit the changes to the database
- After copying the saved config files onto their respective job servers
- Open in Job Service configurator to check the credentials can still be viewed
- Overwrite the existing .cfg file
- Reboot the job server.
As soon as the server comes up, it starts working properly. For a day or two. Then it breaks again.
Has anyone else seen this problem or is it just me?!
For example, this morning I had a job service working fine. I provisioned AD accounts to a test user and watched the processes complete in Job Queue Info. This afternoon I repeated the exact same test with a different account with the same job server processing it (no config changes have been made at all in the last 8 hours).
I've now had two AdHocProjection entries, one for ADS_ADSAccount_Insert and the other for ADS_ADSGroup_Update, both sat with execution status TRUE and dependent ScriptExec functions saying FALSE with dbqueue showing nothing and job queue progress flatlined... for two hours.
The logs give no indication at all that anything's broken. For example right now the logs say
<i>2016-12-07 14:29:58 +00:00 - Info: Last process step request succeeded.<x>
<i>2016-12-07 14:31:41 +00:00 - Info: Requesting process steps for queue \SQL1.<x>
<i>2016-12-07 14:31:41 +00:00 - Info: Last process step request succeeded.<x>
<i>2016-12-07 14:31:41 +00:00 - Info: Requesting process steps for queue \SQL1.<x>
<p>2016-12-07 14:31:41 +00:00 - Process step parameter 5BF7E1DA-1959-4250-A980-46CE519C0ACE:
[Job]
ComponentAssembly=HandleObjectComponent
ComponentClass=VI.JobService.JobComponents.HandleObjectComponent
Task=FireGenEvent
Executiontype=INTERNAL
[Parameters]
ConnectionProvider=VI.DB.ViSqlFactory,VI.DB
ConnectionString=Hidden
EventName=UPDATEUTCOFFSET
objecttype=DialogTimeZone
ProcID=A294E707-F699-411B-880A-C881B97B2765
WhereClause=UID_DialogTimeZone = 'QBM-FF60FBBFC1C18061DF4456004F7B34D2'
_paramName1=StopTime
_paramValue1=2200-01-01 00:00:00.000
<x><i>2016-12-07 14:31:41 +00:00 - Info: Last process step request succeeded.<x>
<i>2016-12-07 14:31:41 +00:00 - Info: Loading configuration parameters...<x>
<s>2016-12-07 14:31:41 +00:00 - VI.JobService.JobComponents.HandleObjectComponent - 5BF7E1DA-1959-4250-A980-46CE519C0ACE: Successful
The event UPDATEUTCOFFSET was triggered for 1 object(s) of type DialogTimeZone.
<x>
Eventually there'll be a Windows event error thrown when trying to verify the connection either by logging into admin tools from the job server or from verifying the SQL credentials inside job service configurator.
Until the file is fixed you can't even the broken Job Service from Job Service Configurator; it complains "the value is encrypted and cannot be displayed" when you go to view the sqlprovider connection string, then after it throws the same error as Job Service Configurator when you go to select the database.
Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=28444; handshake=29498;
The only fix from this point on is to log on to a different job server that is still working, or an admin workstation, and make the change through Designer.
You cannot even stop the One Identity Manager Service once it's in this state - same error code.
Exception occured during Stop.
Database error -2: Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake...
