540
Hi,
I installed Dynamics GP 2015 and when I try to associate a Windows Account from a Trusted Domain its seem that it recognize it, but when I click the Ok button the account its not added to Users -> Directory Account -> Windows Account.
Thanks,
*This post is locked for comments
Hi all, we were finally able to consistently reproduce these issues internally, and we have people looking into it. I will update the thread with anything I hear about it but currently your only workaround is to have your SQL server on the same domain as your workflow users, so that the "fallback" code doesn't fire.
As for the performance, the slowness comes from the fallback code. When the user to whom the workflow should be assigned isn't found in the domain that SQL is joined to, the Workflow Engine queries AD for a list of 'Trusted Domains" and then searches each one of these domains for the user to assign to. If the DC's are offsite, or communication is slow, then this fallback code will take a while to search the other domains. I have more detail in the following blog post, but if NETBIOS name resolution isn't working correctly this can add a performance hit to the lookups.
I'm running into this exact error but only when we use delegate. We are setup exactly how you described above. Did you ever find a solution.
Thanks,
Cathy E.
Thanks a lot for your kind help Dan. Sorry even though our issue is the same but not exactly same. The problem we have is when we add user from 2nd domain the workflow 2.0 process slowdown on submit upto 6 minutes and the approval will end with with following error.
Basically we have 2 forest with different domain and first domain works fine and submit and approval all work well. But the minute we had a AD user from the 2nd domain the workflow maintenance will freeze for few min. And the submit of workflow also will take 6 min. And the approver will get email but after clicking it, this will end up on error. Can you please help me on this, we really wanted to get this resolved to go live with workflow 2.0.
Hi everyone, from what I've learned about this issue, it occurs in a child-parent domain scenario. In my lab environment I had two VMs, each a DC of their own domains, replicated DNS to each other and created an external forest trust between them. I wasn't able to reproduce the issue in this scenario.
I added a third VM, and made it the DC of another domain, this one was a child of another, so contoso3.contoso.com. I set up the trusts and DNS replication, and I was able to reproduce the issue internally with a user from contoso3, using GP machines on contoso1. I added the 3rd domain Friday afternoon, and repro'd on Friday evening. However, by the following Monday morning I wasn't able to reproduce it any longer, and I didn't touch the VM's over the weekend. I also wanted to point out that our internal MSFT domains are configured like this, and I can't reproduce the issue on any of our internal domains reliably. I've had a colleague or two tell me that their GP did it to them using internal creds, but the issue always self-resolves. We can't reproduce for longer than a few hours it seems.
In digging into this issue over support cases, I've come to learn the issue is typically occurring because GP is using System.DirectoryServices to query the user in AD by their AD GUID (which was retrieved from the previous step), and this lookup is failing, so Dexterity can't populate the manager field with the user's friendly name. The initial lookup in the People Picker happens by searching the primary DC you're connected to for whatever you type in the field. This initial lookup is usually working fine. It's the searching users by GUID's that isn't working. I've collaborated with the Active Directory team, and they're telling me that the LDAP queries are coming back correctly and the issue is with the GP code. Querying users using their tools usually works fine. I've had the GP development team look through the code, and we can't see anything that could cause this. They also created a tool to test the lookups, and this code works in these environments outside of GP, but the issue is that the lookup has to perform a 'hop' and switch contexts. The log will show something like this:
10/31/2016 9:38:33 AM: ActiveDirectory.GetUserObjectByDirectoryEntry - There is
no such object on the server.
10/31/2016 9:38:33 AM:
ActiveDirectory.GetUserObjectByObjectGuid - Unable to retrieve user from the
DirectoryEntry object, performing fallback logic to lookup the object across
multiple forests.
It's a System.DirectoryServices DLL error, meaning the debugging has to happen on that level. Part of this is just the nature of how System.DirectoryServices performs lookups.
I'm not sure if the detail helps anyone, but this is one that I haven't been able to determine root cause for yet. The unfortunate thing is that the only workaround is to use users from a different domain, or move users into a working domain. Depending on how the alternate domain suffixes are set up, users could have the same login name, but it's all dependent on the environment. In summary, I don't believe the issue is with permissions to look up the user, my theory is that the issue lies with how the DNS replication, zone delegation, and AD replication is set up in some of these environments, causing lookups to not route to the correct DC where the user resides. I think that GUID lookups do something differently than broad searches, and the issue seems to occur more when the primary DC and primary DNS servers aren't the same server, or the primary DNS server is a third domain resource.
Hi Prem & Dan,
Have you ever resolved this issue with help of Microsoft, we are on the exact position so if you have any update please share the same.
Hello all,
Could I get the error message that populates in your Workflow log? I'm currently tracking this issue internally among a few support cases, but haven't been able to reproduce it at all. I'm curious if everyone else is running into the same error. The logs are located in the following locations:
DynamicsGP_WorkflowGP.log: In the local workstation temp directory of the user who is logged into GP (e.g. C:\Users\user\AppData\Local\Temp)
DynamicsGP_WorkflowGP.WorkflowEngine.log: In the SQL Server machine’s temp directory of the user who is running the SQL Server service (e.g. C:\Users\MSSQLSERVER\AppData\Local\Temp)
The error may not be coming from the Workflow process, but the AD lookups use some shared code so I'm wondering if anything is logging there.
Thanks,
Dan
Microsoft Dynamics GP
Yea I think we may have the exact same behavioural issue. Our problem is that we can select Active Directory users that exist in the Dynamics Domain&Forest, but if we select ANYONE outside of the Dynamics Domain&Forest we cannot see them beyond initially picking them (And bear in mind half the business have never had an Active Directory Account in the Dynamics Domain,).
So if I cant get anything from Microsoft, I need some kind of workaround. Do you have that same issue, employees existing with accounts outside of the dynamics Domain&Forest, if so, how did you sort that??
I'm actually also starting to think how long it will take to migrate Dynamics into the new Parent Forest, sounds a big big job.
This is exactly our problem. Right now our only solution is to have the user login to the the domain that GP is in to and run GP to do the vendor approvals and use old domain login for everything else in their day. Our GP implementer couldn't figure it out and it is a known issue with Microsoft but apparently they are just ignoring it. Please post a repsonce if you get a resolution. Good luck.
Hi grant. Did you get any further info on this anywhere?
I have a very similar problem. A Cross Forest Active Directory architecture, Dynamics GP 2015 in a Child Domain. The Dynamics GP users are starting to create workflows now, and finding that within the Workflow maintenance tool they can see and actually SELECT parent Forest users from the *picker*, but when they click *OK* and return to the admin screen, the user doesn't appear.
This process seems to work fine for users *picked* from the Forest&Domain that Dynamics GP is in, but when they browse into the other AD Forest for a user, it behaves in that weird way (We're in a Merger of 2 Companies IT's, has been going on for just over a year).
I have the Dynamics suppliers working on it, and they've started interfacing with MS, but naturally, AD is getting some attention as potentially being *wrong*!
Sounds like a common thing being experienced. Similar to yours?
Tom
We have this exact issue. We have also applied the 2016 year end patch and it doesn't seem to have fixed it. Have you found the contrary?
#1
Almas Mahfooz
3
User Group Leader
Share
Report
All responses (
Answers (
