Show all fields: Property name has max length 40

I spent some time today with the following error:
The user right-clicked an Advance Invoice record, then chose "Record Info", then "Show all fields" and got the tasty error message below:

Property Name has max length 40. An attempt to set it to a string having length 41 has been made.

You would get similar error messages, if you called the same function on the Advance invoice lines, though then it would say length 45.

The solutions: the SysRecordInfo Form on the SYP layer contains a bug.

The problem is with the line marked with red (duh).

showAllFieldsForm.name('_ShowAllRecords_'+dictTable.name());

The Form's name can be only 40 characters long. The DictTable.name() is "CzCustAdvanceInvoiceTable" (25 chars) + _ShowAllRecords_(15 chars) is too long. Tough luck.

I don't know which KB article dropped the ball on this one, but it's okay in SYS layer, and wrong in SYP layer.

I took the easy way out and simply removed the '_ShowAllRecords_' from the function call, and presto!, it worked.

AX: Original (installed configuration) in registry for new users

The back story

We have a terminal server used by nearly a hundred users simultaneously to launch AX clients. The AX client had been installed a while back, and since then the original AX farm has been extended, some of the servers have been marked as dedicated batch servers, etc. Long story short, the "original configuration" in the registry is pretty much useless at this moment.

Of course they are all using .axc files to connect to the AOS, but unfortunately when AX crashes (and oh boy, does that happen), it nicely offers to restart. However, at restarting it does NOT use the same configuration it was started with, it defaults to the one stored in the registry, and the user arrives to an AOS where he is not supposed to be.

The task

Update both all of the current AX configurations and the default configuration for new users to a correct set of AOSes.

The solution

all users
The users part is pretty straightforward: under HKEY_USERS\<SID>\Software\Microsoft\Dynamics\6.0\Configuration\Original (installeded configuration), the information is stored in the AOS2 and WSDL string values. If you want to add more than one AOS, in then you can list them separated with a semicolon

default user
However the default user profile is not stored under HKEY_USERS\.Default, but is copied from HKLM, when the client launches his first AX using registry. If he always launches AX using an connection file, the registry keys are apparently not created. 

Also, this is where the configuration for Business Connector is stored

The following script will fix all of the above, for all the configs of all the users

#New valid values $AOS2= "AOSSERVER:2712" $WSDL= "8101" #Save current script location Push-Location #Into the registry we go! Set-Location Registry::\HKEY_USERS #Iterating through all the users foreach($sid in $(ls)){ if(Test-Path "\$sid\Software\Microsoft\Dynamics\6.0\Configuration\") { Set-Location "\$sid\Software\Microsoft\Dynamics\6.0\Configuration\" #Iterating through all the configs of the user foreach($config in $(ls)) { Set-Itemproperty -path "$($config.PSChildName)" -name "aos2" -Value $AOS2 Set-Itemproperty -path "$($config.PSChildName)" -name "wsdlport" -Value $WSDL } } } #HKLM stores the default users config, should only have the Original (installed configuration) config, #no need to check all the configs here Set-Location Registry::\HKEY_LOCAL_MACHINE\Software\Microsoft\Dynamics\6.0\Configuration\ Set-Itemproperty -path "Original (installed configuration)" -name "aos2" -Value $AOS2 Set-Itemproperty -path "Original (installed configuration)" -name "wsdlport" -Value $WSDL #Back to the original path Pop-Location

Remote Desktop Connection Manager (rdcman.exe) 3334 problem

On Windows 8, Remote desktop connection manager has the annoying habit of throwing unexplainable error messages after opening more than a couple of connections, with error code 3334

If you are managing dozens of development (or live) environments, this is bloody annoying.

I have seen several proposed solutions on the net for this problem, this is the one that worked for everyone in our office, but as always, your mileage may vary.

1. Open a Visual Studio Command Prompt with Administrative priviliges
2. cd "c:\Program Files (x86)\Remote Desktop Connection Manager"
3. editbin /LARGEADDRESSAWARE rdcman.exe

After this (at least for us), rdcman just works like it's supposed to.

AX installation needs file sharing to be enabled on the SQL server

Today during an AX installation I got the following error in the DynamicsSetupLog.tct


Checking for the existence of the service 'MSSQLFDLauncher' on the machine 'SQLSERVER'.<br /> *** ERROR ***<br /> Cannot open Service Control Manager on computer 'SQLSERVER'. This operation might require other privileges.<br /> Cannot open Service Control Manager on computer 'SQLSERVER. This operation might require other privileges.<br /> The root cause was that the SQL server (a Windows Server 2012) didn't have File sharing enabled amongst its roles, so AX couldn't verify if an SQL component was installed. Solution: After I enabled file sharing on the target server, the setup continued without any further problems.

AX 2012 R2 crashes while synchronizing with TFS - KB 2902776 to the rescue!

I had a very frustrating error on the development servers I oversee (each developer has their own virtual machine): when a new environment was created it simply wouldn't sync to the Team Foundation Server code repository.

If you clicked on Synchronize and selected the model, it would think for a bit, then 90% of the time, it would crash. Opening the sync log and trying to Process the failed elements would lead to the same AppCrash error.

Deleting the AX local caches didn't help, restarting the AOS, doing full compile, full CIL compile, nothing would help. Recreating the database would sometimes have an effect, but that's it.

Thankfully there is a solution:

KB2902776 solves the issue. Unfortunately it is only available from PartnerSource (which is not indexed by Google), so it took a bit to find it.

It is a model update of the Foundation model, so I assume there is a code error in the SysXXXX class that does the synchronization.

After installing the hotfix I did a full compile/sync/CIL compile cycle before trying it, no clue if that's actually necessary, but as there was a model update, you are supposed to waste two-three hours with it.

Hope it saves others some frustration!

Adding a computer to a domain with Powershell

If you have to add lots of computers to a domain, (after launching sysprepped images for example, that already have their new computername), then the following script might come in handy, and save you some password typing.

This is a shortcut, of course, and a slight security trade off.
If you are not comfortable copy-pasting your password into powershell windows as cleartext, don't use the script!

$password="XXXXX"|ConvertTo-SecureString -asplaintext -force $username = "DOMAINNAME\USERNAME" $credential = New-Object System.Management.Automation.PSCredential($username, $password) $computername=$env:Computername Add-Computer -DomainName "domainName.local" -Credential $credential -ComputerName $Computername -Restart

Turning off UAC in Windows 2012 R2 with Powershell

In Windows 2012 R2, the slider that we used to use for turning off UAC (User Account Control) does not really work. It is there, but when you adjust it to minimum, nothing happens, it doesn't even ask for a reboot.

Apparently, you have to manipulate the registry to turn the damn thing off.

The following powershell command, if executed from an Admin powershell window will do just that (and immediately notify you, that you need a reboot)

set-itemproperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system -name "EnableLua" -value 0