More Tricky Dynamics Web Services Stuff
Convoluted.
That's the one word that comes to mind when I think of the whole Dynamics GP Web Services configuration.
Maybe it's just our environment that has been the cause of my lack of sleep? After having spent as much time as I have searching through blogs, forums, newsgroups, and technical articles, I have to believe that I am not the only person who has run into these sorts of issues.
The thing that prompted all of this was a request by the internal developers of our order system (which interacts with GP) to be able to use the special AD account that we had set up for them and access the "DynamicsAdminService.asmx" page. I had already gone through a few months ago and fixed the problems that we were having with accessing Dynamics via IIS in general, and so I assumed that most of the pain was behind me. I was wrong.
Since I was unable to find any good documentation anywhere, I decided to at least post some notes on what I did here for others to find. A couple of interesting things:
Verbose IIS Logging
As part of my troubleshooting process, I learned how to enabled some advanced, verbose logging in IIS. All of the sites that I found when Googling around made this seem very complicated and/or didn't completely tell you how to do it. All you need to do is this:
1. Create a "Provider" file. This is just a text file that you will need to use when you start logging with the "Logman.exe" utility later. Since I was really just interested in verbose logging for ASP and IIS in general, I used the example that is found on this TechNet page and saved it as "trace.txt" to my C:\Inetpub directory.
2. Use the logman.exe utility to start verbose logging. From the command prompt, it went like this:
logman.exe start IISTrace -pf trace.txt -ets
...Now that the logging process is running, I went and tried to reproduce the authentication problem I was having by browsing to the /dynamicsadminservice.asmx page from another machine and using the credentials I was having problems with. After receiving the expected "Access Denied" message, I went back to the server and stopped the logging process as follows:
logman.exe stop IISTrace -pf trace.txt -ets
This left me with an .etl file in the same directory as my trace.txt file.
3. Now, if you spend a little time trying to figure out the best way to read the contents of an .etl file, you'll find that most of the results you come up with talk about some fairly time-consuming methods. However, I stumbled across this simple solution. Just run this command:
tracerpt IISTrace
That will give you a nicely formatted dumpfile.csv that you can view in Excel. Voila!
Granting Access to the Dynamics Security Web Interface
Listed as the "Dynamics Security Admin Service", this web site is initially only accessible by the user who installed Dynamics Web Services. Also, it can normally be found on port 49152 for HTTP, or 49153 for HTTPS (assuming you have installed a certificate).
I had to go through the following steps to grant access to another user:
1. Open the Dynamics Security Console and make sure the user is added as a Superuser under the "Role Assignments".
2. Make sure the user is granted permissions to the web site itself under IIS (right-click the site and select "Permissions" to find this).
3. Add the user to the "Authorization Rules" section in the configuration settings for ASP.NET. To find this, go into the properties of the web site, then to the ASP.NET tab. Another window will appear... go to the "Authorization" tab and add the user to the "Local Authorization Rules" with "Allow" permissions, and be sure to bump them above any "Deny" rules.
4. Make sure that the user has permissions to SQL.
5. If you are still running into trouble, in some cases, you may need to make sure that the user has at least "Read" access on the file system to every folder in the path where the site exists (Normally, C:\Program Files\Common Files\Microsoft Shared\Microsoft Dynamics\Security Admin Service\WebServices\).
It would really be convenient if simply adding the user to the Security console would do the rest for you, but then again I suppose things just wouldn't be as fun.
In any case, I was finally able to grant access to our other AD account and our developers were happy. I hope that this information will be useful to someone.
That's the one word that comes to mind when I think of the whole Dynamics GP Web Services configuration.
Maybe it's just our environment that has been the cause of my lack of sleep? After having spent as much time as I have searching through blogs, forums, newsgroups, and technical articles, I have to believe that I am not the only person who has run into these sorts of issues.
The thing that prompted all of this was a request by the internal developers of our order system (which interacts with GP) to be able to use the special AD account that we had set up for them and access the "DynamicsAdminService.asmx" page. I had already gone through a few months ago and fixed the problems that we were having with accessing Dynamics via IIS in general, and so I assumed that most of the pain was behind me. I was wrong.
Since I was unable to find any good documentation anywhere, I decided to at least post some notes on what I did here for others to find. A couple of interesting things:
Verbose IIS Logging
As part of my troubleshooting process, I learned how to enabled some advanced, verbose logging in IIS. All of the sites that I found when Googling around made this seem very complicated and/or didn't completely tell you how to do it. All you need to do is this:
1. Create a "Provider" file. This is just a text file that you will need to use when you start logging with the "Logman.exe" utility later. Since I was really just interested in verbose logging for ASP and IIS in general, I used the example that is found on this TechNet page and saved it as "trace.txt" to my C:\Inetpub directory.
2. Use the logman.exe utility to start verbose logging. From the command prompt, it went like this:
logman.exe start IISTrace -pf trace.txt -ets
...Now that the logging process is running, I went and tried to reproduce the authentication problem I was having by browsing to the /dynamicsadminservice.asmx page from another machine and using the credentials I was having problems with. After receiving the expected "Access Denied" message, I went back to the server and stopped the logging process as follows:
logman.exe stop IISTrace -pf trace.txt -ets
This left me with an .etl file in the same directory as my trace.txt file.
3. Now, if you spend a little time trying to figure out the best way to read the contents of an .etl file, you'll find that most of the results you come up with talk about some fairly time-consuming methods. However, I stumbled across this simple solution. Just run this command:
tracerpt IISTrace
That will give you a nicely formatted dumpfile.csv that you can view in Excel. Voila!
Granting Access to the Dynamics Security Web Interface
Listed as the "Dynamics Security Admin Service", this web site is initially only accessible by the user who installed Dynamics Web Services. Also, it can normally be found on port 49152 for HTTP, or 49153 for HTTPS (assuming you have installed a certificate).
I had to go through the following steps to grant access to another user:
1. Open the Dynamics Security Console and make sure the user is added as a Superuser under the "Role Assignments".
2. Make sure the user is granted permissions to the web site itself under IIS (right-click the site and select "Permissions" to find this).
3. Add the user to the "Authorization Rules" section in the configuration settings for ASP.NET. To find this, go into the properties of the web site, then to the ASP.NET tab. Another window will appear... go to the "Authorization" tab and add the user to the "Local Authorization Rules" with "Allow" permissions, and be sure to bump them above any "Deny" rules.
4. Make sure that the user has permissions to SQL.
5. If you are still running into trouble, in some cases, you may need to make sure that the user has at least "Read" access on the file system to every folder in the path where the site exists (Normally, C:\Program Files\Common Files\Microsoft Shared\Microsoft Dynamics\Security Admin Service\WebServices\).
It would really be convenient if simply adding the user to the Security console would do the rest for you, but then again I suppose things just wouldn't be as fun.
In any case, I was finally able to grant access to our other AD account and our developers were happy. I hope that this information will be useful to someone.
Comments