We recently had to add a user to an app that uses the Dynamics GP web services. Since the web services seem to only allow you to assign permissions to individual users and not Active Directory groups, I was required to go into the Dynamics GP Security Console. Sadly this often turns into an adventure in error messages and this time was no different.
First the console errored out at the top level. A little digging and I discovered that of the three app pools setup by the GP Web Services in IIS, GPWebServicesAppPool, DynamicsSecurityServiceAppPool and DynamicsSecurityAdminServiceAppPool, the first two were using the service account we’d originally setup for this. The DynamicsSecurityAdminServiceAppPool, however, was using an administrator end user’s account. Not exactly best practice.
Anyway, figured that changing it to the same account as the other two app pools would do the trick. And so it seemed. I was able to open up the Security Console and navigate down to the policies node, usually the mark of a functioning console.
However, when I went to add the new user to the appropriate application level group, I received an error message when I clicked Apply, “An unexpected error has occurred. See the event log for further details.”
So into the event log I dove and found the following error:
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Pretty much left me stuck. A couple of emails back and forth with MS support and it turns out that during the Web Services installation, another account is created, DynamicsGPAdm. This is a local account and is apparently given additional privileges beyond those of a local administrator. I’m guessing that these are to ADAM.
Of course, I had no idea what the password was as this was setup during the install, but fortunately, this account isn’t used for anything else. So a quick password change and an update to the app pool and I was back on my way.
However, the complexity (do we really need three separate app pools?) and fragility of the GP Web Services, is one of the main reasons I’ve moved away from using them have moved creating my own web services using eConnect directly. ADAM may be a great idea in theory, but it has caused me no end of grief.