Deploying Dynamics AX 4.0 Client in an Enterprise Environment

[gn!uz]

Enterprise deployment of the Dynamics AX 4.0 Client seems impossible without
making end-users local admins, power users or applying the
AlwaysInstallElevated policy! This is ridiculous, and not very Microsoft to
be honest!

Please, tell me and others what we have to do to get this thing working...

Question 1: Is it possible to install the Client only and without ANY
configuration parameters? (And no, no AOSServer either!)

Question 2: Is it possible to install the Client using the local SYSTEM
account (used by enterprise deployment tools SMS/Radia).

Question 3: Is it possible to use the Client.msi for Client installation
instead of the Setup.exe (what properties have to be modified to remove the
check for setup.exe)

Question 4: Can the Client software be installed by the Client (user) only?
If so, why? Which specific user-settings cannot be added when using
advertised shortcuts?

I'm becoming more and more frustrated over the situation.. I've read the
implementation guide and I've tried ALL possible parameter combinations.. So
far no luck..

What I would like to accomplish:

Create an unattended Client.MSI (or Setup.exe) installation without any
shortcuts, without any configuration parameters and use custom shortcuts that
point to the desired environment ax32.exe \\server\config\bla.axc

Makes sense?

Please provide us with proper enterprise deployment instructions asap....

Thanks

--
// Freedom is a road seldom travelled by the multitude

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/Businesssolutions/Community/NewsGroups/dgbrowser/en-us/default.mspx?mid=d1064b64-c8a3-4cad-b088-bba198321136&dg=microsoft.public.axapta

[RCarney]

Is this your first AX installation? If so, I can understand it might be
frustrating. Is the bottom line that you are simply just trying to have an
AX icon for users that points to different instances of AX without having to
edit the configuration for the client? If so, there are ways to do this very
easily. Let me know.

[Brandon]

I interpreted his post that he was trying to deploy the client to a large
fleet of workstations and was frustrated at having to do so manually. Since
his users are not local Administrators (and they should not be), he can not
use a login script or send work instructions to them and have them do it.
The client does not support Active Directory Group Policy deployment
(puh-lease).

It would seem promising that the client.msi could be made to deploy by group
policy (avoiding the setup.exe altogether), but I never got this to work
either.

Some suggestions for you --

1. Repackage the client into your own MSI using repackaging software. With
experience this can be done fairly quickly, but if you've never done it
before it will be a learning curve, and the MSI you create will not be as
flexible as Microsoft's. For example, it will be tied to C:\Program Files,
so if you need it to install on another path like C:\Program Files (x86), it
will not. But, depending on your environment this may be a great solution
for you.

2. Deploy with a login script and use RUNAS to temporarily elevate to an
account with installation rights. You could create a domain account just for
this purpose and then disable it later once the deployment is finished. The
risk here is that the credentials for that account are stored in plaintext in
a .BAT file.

[Boomer]

I've fought this battle as well. Visiting every machine to install the
client (or a patch/SP) is not practical in an enterprise environment.
Unfortunately, I haven't found a foolproof workaround.

I've attempted the runas option using CPAU to encrypt the password and it
works OK with a one function script. Unfortunately, you can't do more than
one "thing" per script. I've written a script that tried to install the
client, install the updated help, sp2 and copy a shortcut to the desktop, all
called in a CPAU job. However, once the script launches the first setup, it
moves on because all the setup does is call the MSI and the script thinks
that line is finished and the script can continue on. When that happens
everything goes haywire as you end up having a bunch of things running, or
not, when the script finishes and usually AX is partially installed(not
functional) and none of the updates applied. I've tried to put a poor man's
"wait" in the script, a single ping to a non-existant address with a five
minute timeout, to give the client time to install before the script moves
on. Depending on PC and load that may not be enough time. Hopefully a
solution exists...

[gn!uz]

Ok, I don't know what happened but suddenly it seems my 'problem' is fixed..
Getting rid of the ClientConfig=0 property will save you a lot of trouble!!

I will describe in detail how I managed to get the Client installed using a
deployment tool (Radia in our case). If there is anyone who needs more info
please let me know...

First I created a LIS (Local Installation Source). It contains all the
original source files plus a custom made executable Inst_Dynamics.exe (using
Wisescript). I deploy this to my clients first.

Then I deploy a new job to install the actual client and initiate the
installation from the local source.

Final step is another job adding the shortcuts....

Usage: Inst_Dynamics.exe <parameters>

Parameters:
install (installs the clients)
uninstall (uninstall the client)
add test (only adds test shortcut)
add development (only adds development shortcut)
add production etc...

The command string I used for client installation:
- setup.exe HideUI=1 AcceptLicenseTerms=1 LicenseTermsVersion=en-US
InstallClient=1 ClientLanguage=en-US
ClientAOSServer=<server1>;<server2>;<server3>

The command string I used for client removal:
- msiexec /x <LISPath>\Msi\Client\Client.msi /qb!
- delete file(s) C:\Program Files\Microsoft Dynamics\*.* (inc. folder)
- delete %ALLUSERS%\Start Menu\Programs\Microsoft Dynamics AX\*.* (removes
custom shortcut(s) and folder)

The custom executable waits for the installation process to finish. It will
then start a loop to check for the availability of the default Dynamics
shortcut. It will be deleted as soon as it is found.

The custom executable is also used to install the custom shortcuts pointing
to their specific environment, for example:
- C:\Program Files\Microsoft Dynamics AX\40\Client\Bin\Ax32.exe
\\server\install\dynamics_test.axc

And there you have it!! Very easy if it's works... It's too bad this thing
has cost me so much time. If anyone wants the script/executable just ask...
It's easy to modify to your needs!

I've tried repackaging this as well but didn't seem reliable. Some problems
registering dll's.

Thanks!

Martijn

--
// Freedom is a road seldom travelled by the multitude

[de.r...@almavivaitalia.it]

I suggest another way...

Why you don't thik to install AX client in a dedicated terminal server
environment? It is very much simple to manage...

Regards

Denis Rossi