Monday, March 03, 2008

Do and Don't Lists

As an added service to you the developer or administrator, I have created two lists named "Do" and "Don't", respectively. This is a quick hit list of things that you should at bare minimum entertain the idea of researching the possibility of implementing or definitely not doing at all.

You will see these lists in the right margin at the end of the 'widgets'. If you have a personal lesson learned that you think should be in the list, please send me an email.



Genious said...

Hi David,

Nice blog, I am visiting your blog from may/June 2007. Nice work.

We were in the process of scoping exercise and now we done installation and basic configuration, hope to go live in July 2008.

Just want to discuss, one issue if you feel comfortable. I though you got plenty of experience.

Let me tell you scenario, we have purchased 20+ licenses. We are hosting Ax server on the third party servers.

Now our system admin came with plan that we will use Cisco VPN client to access the firewall and then remote desktop to AX server.

However, as a developer I was expecting Ax server will be accessed through the AX client installed on the every user’s PC.

Please leave any response. Which approach is better any pro and con’s.
My personal e-mail is

I will really appreciate that.
Sorry to post as a comment, as I haven’t got your e-mail.

Many thanks,

David Bowles said...

Mahmood, when I used the email address you supplied, it bounced back. I just decided to drop the email here for you:


My personal email address is

The reason why your administrator wants to have you terminal server (RDP) into machines that are located elsewhere rather than installing the fat-client on the desktop of every user has to do with the amount of data that will be travelling between the users and the server. With the 'terminal server' configuration, the only data that will be travelling between the servers and your users is the screen shot frames for the RDP program. With the 'fat-client' scenario, all the data that a user will be accessing will be pulled from the server over to the local machine across the network. In an situation where, if you were like us, and have a 60,000 record InventTable, if someone were to try and sort that or even copy all the lines across to excel, you'd probably kill your network connection unless you have something like an OC-3 or higher. That also may be the main reason why the administrator wants to setup is you may only be running off of a T-1 or T-3.

A second smaller reason to use RDP for access is the ease of administration. Your administrator only has to setup AX one time on the Terminal Server and does not have to walk around to every machine and install/uninstall the software. While there is a feature to do a remote install now in AX, Terminal Server is just a much better strategy overall for deploying AX, in my opinion.

We are setup in a terminal server environment, too, however we have a 100Mbps connection between our location and our servers, which are across town, and we still even see some sluggishness from time to time. If we had our end users with fat-clients it would be much worse. One user could hose the network with one mistaken sort or clipboard copy/paste.

If you have any other questions for me, don't hesitate to ask.


David Bowles

Genious said...

Hi David,

First of all thanks for quick reply.
Yes, I am quite convinced now with this solution.

I was reading about the new release of BizTalk Server 2008 R2. It has new Adapter for MS Dynamics.
Does it mean that we don't need AIF for integration of Ax with other application?

If we still need AIF, then what will be the role of BizTalk Adapter in R2 release?

I will really appreciate that.

And sorry about e-mail, that was misspelled. The right one is

Many thanks,