I wrote the DynamicsAxCommunity Powershell module quite a few years ago to help me with a project where I was building and deploying several AX environments across many servers. You still can see some design decisions from this old project, such as what kind of actions I needed and the emphasis on remoting (e.g. I can simply call Start-AXAOS UAT and the module connects to the right remote machine and starts the right service there).

Since then, the module didn’t get any major features, but it’s still maintained and extended as needed. Some modifications were triggered by changed reality (such as the introduction of AxBuild), some by changes in usage. For example, although the module was originally written mainly for automated deployments, I started using it more interactively. I often use Start-AXClient instead of AX configuration files (e.g. Start-AXClient UAT -Layer VAP -Dev), which required a few extra parameters such as -Layer.

There are surely things that could have been designed better (such as some parameter names), but now it’s too dangerous to change them. It could easily break existing scripts.

That being said, the latest build brings (among some fixes) a potentially breaking change, but I believe it can be justified. Without going too deep into details, the module used to ask for credentials before the first call to any remote machine and then tried to cache the credentials and used them for subsequent calls. The fundamental flaw was that it asked for credentials even if the remote machine was configured not to require them. The new implementation never calls Get-Credential and tries to execute the remote command even if you don’t provide any explicit credentials. It’s up to the remote machine to accept or reject the call.

I hope it won’t cause any troubles and it will actually make your life easier.

You can find a brief description of other changes in the change log and you look into source code for details.