eConnect Vs GP Web Services – Chris Roehrich


This is an awesome post from Chris Roehrich on Developing For Dynamics GP blog.

The post explains very neatly (and in detail) about the differences between eConnect for GP and Web Services for GP.

And which one to use or not to, is up to you after you read this post. There are some interesting short discussion on the comments section, so do read the comments as well.

That’s an excellent post, Chris. That surely would have answered several questions from users/consultants across the world.

VAIDY

Advertisement

DynamicsGPAdm User Account for DynamicsSecurityService (Web Services)


Looks like I am bound to troubleshoot and maintain more today. But since that’s the case, I am having a chance to revisit what I have done while installing and configuring the current GP + CRM + Adapter + WebServices.
Having said that, I just cleared one issue and thought I would share post it.
When we install GP Web Services, a Local User Account called DynamicsGPAdm will be created and it will be added to IIS_WPG and IIS_IUSRS group. 
It was all fine till I found that the Dynamics Security Console did not show the necessary details. All I was seeing is a big red X error message and with that a message saying “Console is corrupted or invalid data, blah blah blah…”. Honestly, I was extremely scared to see this, as I was under the impression that everything was fine. I still believe everything was fine, because my GP10-CRM4 Adapter is working as good as it was for the past 2 months.
I had to revisit what I had done to install and checked all IIS Security & Services Security. Everything was perfect till I saw one glaring gap.
The Local User Account DynamicsGPAdm was created with our Server’s Password Policy enforced on it. That means, typically:
1. This account has to change it’s password when it logs on to the server for the first time. (Never happened till date).
2. Password expires in such-and-such days. (The number of days had in fact exceeded in this case).
3. Must meet the Password Requirements. (It obviously didn’t).
Perfect. I kinda hit it on the nail this time. 
I first changed the password of this User Account to meet the Password Requirements. Next I did as shown below:
Just make sure that once you install Web Services, the DynamicsGPAdm must be configured as above.
Significance of DynamicsGPAdm: This is the account which is configured in the Identity of DynamicsSecurityAdminServiceAppPool IIS Application Pool, which is the base for Dynamics Security Service and Console.
VAIDY

AD LDS & GP Web Service on Windows Server 2008 64 BIT- Workaround


Blown away by this issue and am feeling great to cross a mysterious hurdle.

I was trying to install GP Web Services 10.0 SP4 Hot Fix NOV2009 on the following environment:

1. Windows Server 2008 R2 64 Bit
2. GP 10.0 SP4
3. CRM 4.0 Rollup 9
4. SQL Server 2008 SP1 64 Bit

One of the pre-requisite for Web Services is AD LDS (Active Directory Lightweight Directory Services). This needs to be installed on Windows Server 2008 and no configuration required post installation. GP Web Services will take care of creating an Instance on AD LDS and use it for it’s Data Storage on this AD LDS instance.

I crossed all those steps and started installing GP Web Services and got this message without any delay after double clicking the installer:

The Active Directory Lightweight Directory Services role must be installed on the computer before installing the Microsoft Dynamics GP Web Service.

Nothing other than the above message and I was quite blown away by it’s vagueness. After much exploration, I got the following link from Sivakumar:

Description of the 64-bit operating systems that are supported together with Microsoft Dynamics GP

In that article there is a section called Web Services Runtime Workaround under which there is a subsection called Windows Server 2008 x64 or x86 and Microsoft Dynamics GP 10.0 only, which explains the workaround.

To Summarize the Workaround: With Windows Server 2008 R2 64 Bit, the GP Web Services installation does not identify the AD LDS being installed. It requires a Registry Entry called ADAM_Shared with a registry value, that needs to be created under HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion.

We must be carefully following the steps to avoid any consequences.

For those who do not have access to CustomerSource / PartnerSource and are struggling with this issue, comment on this article or email me to my ID: vaidy.dyngp@gmail.com.

Thanks to Sivakumar & Prem (Elcome’s Sys Admin), who were instrumental in sending this link to me on time and clearly saved my day.

VAIDY