Am I correct in believing that the Logon credentials for the Messenger service are the ones used to execute external programs? If so, I think I’ve fixed a problem that has been vexing my team for months. If not, I’m going to continue to have troubles here.
By default, the same credentials are used for all Workflow modules and services, including Messenger. Although you could change those credentials through the Windows Services app if you wanted… but I’m not sure why you’d actually want to do that.
Can you share a little bit more info about the troubles you’ve been having?
That’s what I thought (and as it should be).
For several months, even though I’ve logged in as the domain admin account being used to logon as a service, I’ve noticed that the configuration always said it was a different account.
When OL Care helped me reinstall this week, there was a brief discussion about credentials and best practices and when I went to set up the logon as a service account in Workflow as before, I noted that instead of <user>, it was pulling @.. In theory, that’s the same, but when I corrected it to <user> it told me it was different from the account I was logged on as.
After some playing around, I realized today that Messenger had this same account configured (<user>, but maybe didn’t have the password correct. Once I fixed that, Workflow said that I was using the same account as the logon account.
Since the reinstall, I’ve had problems where processes involving external programs failed to run the external program unless I was debugging. I’m asking this to see if these are related, and if so, if this fixes the problem I’ve been having.
Well Messenger isn’t in charge of running external programs; the Watch Service takes care of that. If those programs run in dbug mode but not in service mode, then you definitely have to double check the Workflow Service account (aka ppwatch8)
Note that as far as credentials are concerned, we’ve often seen cases when a local account has the same name and password as a domain account. Depending on your company policies, the credentials for the local account may be overridden by those of the domain account, which can sometines lead to hard–to-identify issues.
Shouldn’t have problems with local vs. domain accounts, but I had really hoped I’d figured this out with that.
To be clear, I just tried the production mode for one of these processes that was failing and it did work now.