Common AADS related issues..
Most AADS issues are related either to incorrect installation or to the interference of third party software. To assist you in resolving your issues as quickly as possible please begin by doublechecking your configuration against the checklist.
AADS and Anti Virus Software
90% of all AADS support requests are caused by antivirus blocking AADS communications and process, therefore it is necessary to ensure that All AADS files and process are set as exemptions in your AV software.
If you are using Windows Defender, AADS will now automatically configure these exceptions for you.
AADS will not work reliably with the following Antivirus products and will not be supported by us if used.
In addition to the checklist we have compiled a list of various issues and causes for your convenience but please be sure to start the process with the checklist.
AADS complains that administrators should have full access, even if it is installed with an administrative account:
Turn off the Anti-Virus software on the machine. AADS replaces a few system components and AV software may block the installer from doing this. As a result, AADS thinks it has no write permissions and the installation fails.
AADS states that another installation is waiting for a reboot.
AADS can’t install, if the machine is still waiting for a reboot to finish a previous software (un)installation. Reboot the machine and try again. If it still doesn’t work, then it’s possible the appropriate registry key wasn’t cleared properly. If this is the case, it needs to be cleared manually. Follow these instructions.
The computer was a member of a domain and after AADS was installed, it is not.
This is normal. AADS will always take a machine off the domain it is joined to. Classic editions cannot be domain members and Enterprise editions are joined to the domain by AADS itself. When a server is shut down, AADS will take it off the domain and when AADS starts, it joins the machine to the domain again. This is just how AADS works.
The installer reports “Licence can’t be verified for administrative reasons”
There is another cause for the problem. AADS can only be installed a certain amount of times within a time period. If the number of installation attempts exceeds the max number of permitted installations, the licence will be flagged as bad. The reason for this is to protect the licensing algorithms.
Installer becomes non responsive at “AADS is being installed”
Check the temp folder for existence and write access. AADS is looking for %windir%\Temp and needs write access to it or the installer can’t run properly and the terminal server can’t start.
Installation fails with “Wrong terminal services version”
Make sure the installed Windows is not modified. Microsoft made XP multi user capable but disabled the functionality to permit multiple concurrent users. There are hacks out there, which modify some Windows components like “termsrv.dll” in order to reactivate the functionality. AADS cannot run with these modifications and will therefore check the appropriate components before the install. If it finds modifications, it will not install.
Also, Sony sold several computers, mainly notebooks, with a modified version of XP, which will also fail the test by AADS and it is not possible to install on these OS versions.
Users log on and immediately get disconnected/logged off
This is frequently caused by the Video driver on the AADS machine. Check the event logs for RDPDD errors. If the video driver on the server is faulty, AADS won’t be able to create a desktop session. Up- or downgrading the video driver usually fixes the issue.
It is also possible that the session image space of the machine isn’t big enough to hold both, the systems video driver and the display driver for the RDP session. To adjust the session image space, open the registry editor and navigate to [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management] There should be a Dword value called “SessionImageSize” with the default value of “0x00000010”. Increase this value to “0x00000020”. This will double the session image size and the problem should not occur anymore
On a Windows 7 or Server 2008 R2 machine, there may be a different cause and solution for the problem. Microsoft has released a patch for a security vulnerability in the RDP implementation. If this patch has been installed and SP1 is applied to the machine, no further remote desktop connections are possible to this machine. Users connect, get a logon screen and right after logon, they get disconnected. AADS will not show any trace of the problem in its logs but the system event log of the machine will report after each logon attempt, that the Remote Desktop service has crashed. There will also be a corresponding entry in the application event log about SVCHOST.EXE crashing. The cause for this is a different version of rdpcorektml.dll, which will cause the RD service to crash. To fix the problem, security patch 2667402 needs to be installed. For more info, check out http://support.microsoft.com/kb/2667402.
Users get disconnected frequently
This is quite often caused by the NIC driver on the AADS machine. Check the event logs for TermDD (Terminal Server Device Driver) errors, especially event 56. This can be caused by a faulty NIC driver but also by a faulty NIC itself. Make sure the NIC is not set to automatically negotiate its speed/duplex settings and in case of a Broadcom based NIC, disable "Scalable Networking". If in doubt, try a different NIC, preferably one Windows has onboard drivers for.
Users log on and all they get is a screen with a blue or green background
This happens occasionally but isn’t normally connected to a problem. Often killing the session will fix the problem. It may also be necessary to reboot the server.
It can however be a problem related to AV software or unsuitable software like printer or motherboard utilities. First guess would be AV though. Disable AV and try again. If it works, you need to adjust your AV settings or change your AV solution altogether.
It is also possible that some process has a lock on a user’s registry file. In this case, AADS can’t load a profile and sits there waiting for the lock to be lifted. In this case, it’s necessary to reboot the machine.
AADS reports that the licence is not OK
Check the licence history. If the licence is ok, the problem is most likely caused by printer utilities and/or chipset/motherboard utilities. This also manifests itself in a lot of log file entries regarding “CSRSS.EXE” being idle. These programs have the tendency to disrupt the communication between the terminal server process and some of its components. As a result, the licence is deemed to be “not OK”, as far as the local system is concerned. This does not mean that there is a real problem with the licence.
Of course it is possible, that the licence is really bad. To be sure, get the licence history and check.
AADS can’t join the domain
This can have multiple causes. AADS can be rather weird when it comes to joining a domain. In some cases, it is required to use the FQDN (like DOMAIN.local), in some it only wants the actual domain name. It is also sometimes necessary to put the NetBIOS server name in the appropriate text field.
Do not attempt to join the machine to the domain through the Windows mechanisms. AADS will take the machine off the domain when you restart the computer. AADS is designed to do the joining to and disjoining from the domain itself.
AADS is running on Server 2003 and only administrators can log on/only 2 users can log on.
Terminal Server Licensing needs to be installed on the server. AADS requires some binaries and DLLs, which are installed with TS licensing. It may also be advised to disable the terminal server process on the machine.
AADS Server 2008: At log on message says user is not part of the terminal services group.
Terminal services licensing must be enabled and users added to the terminal services group. If that has been done and problem persists see the following. As I'm sure you're aware a Terminal Server is not recommended on a DC for security purposes!As for the actual problem at hand, a DC usually modifies the list of groups who can login remotely. Run an rsop.msc at the DC and check in “Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment”. Look at both the "Deny logon through Terminal Services" and "Allow logon through Terminal Services". Next, you need to open “Group Policy Management” and edit the “Default Domain Controllers policy” - this is the reason why a TS on a DC is a security risk. Anyway, you will need to remove any generic groups such as “Domain Users”, “Users” etc. from “Deny Logon Through TS”, then add the “Remote Desktop Users” to the “Allow Logon Through Terminal Services” entry. Then “gpupdate /force” and try a login again. Not the best solution because users now have access through TS to all DCs, but at least they won't be admins on those DCs.
The AADS machine was rebuilt/hardware has been changed/added and AADS says the licence is not OK.
When installed on a machine, AADS will create a machine ID out of the amount of RAM, the Windows SID and some other hardware components. This ID is stored on the local machine and transmitted to the licence servers during installation. When Windows is reinstalled, the SID changes and the machine ID is not the same as AADS expects it to be. In this case AADS simply shuts down. The same goes for hardware changes. In either case, AADS needs to be reinstalled. While adding RAM or adding some disks, is considered a minor change and AADS will allow to reinstall without a problem, the licence must be reset before AADS can be reinstalled in case of a Windows reinstall or a major hardware change.
The AADS machine will be replaced and the settings for application control are needed on the new machine.
Export the registry key HKLM\Software\AADS from the old machine and import it into the new server BEFORE the installation of AADS. During installation, AADS will fix the registry to suit the new install, keeping all the settings for app control, farming etc. It may be an idea, to export the registry key after every major change and keep the .REG file on a different machine in case of a major disaster.
AADS doesn’t answer when configured to use port 3391.
The last build of AADS introduced a feature called RDP plus. RDP Plus is used for “driverless printing”, similar to “Easy Print” in Win 7 ultimate and Server 2008 R2. This feature uses port 3391 as default. This port needs to be changed before AADS will be able to use 3391 as RDP port. To change the port, open the AADS maintenance panel, click the “Terminal Services” tab. Right beneath the tab bar, there are two smaller tabs, labelled “RDP (standard)” and “RDP plus”. Click the “RDP plus” tab and change the port to something other than 3391.
Licence not OK, machine is very slow to start and no log files are written
We've come across the problem recently. AADS installed without a problem but the machine took about 4 times as long to start afterwards than normal. When the machine came back up, the licence was "not OK". A quick look at the licence history revealed that there was nothing wrong with the licence and in fact, the machine hadn't been talking to the licence servers. When checking the AADS logs, we've noticed that they weren't updated at all and the process "ipc_termsrv" wasn't running. A bit of testing and checking revealed that the Identity Protection of AVG was enabled. It prevented AADS from starting or contacting the licence servers, which in turn slowed the computer down dramatically during start-up. Deactivating the Identity Protection immediately fixed the issue after a reboot.
The software is not installed correctly (message on login)
Antivirus is blocking access to the init file. Exclude the AADS program folder and all of its processes from scanning, then reboot. In most cases, you will not need to reinstall but occasionally, AV can actually damage things and a reinstall is on the cards.
Client only displays "Securing remote connection..." but never connects
This is caused by a bug in MS-RDP. We do not know whether it is MSTSC that's faulty or a library it uses. This doesn't affect all machines and is a bit hard to trouble shoot but there is a workaround:
Edit the .RDP file used to connect and add the line enablecredsspsupport:i:0 to it. This ensures MSTSC isn't using CredSSP and the connection succeeds. While this only seems to occur since the April 2015 build, it is known to have occurred when connecting to Windows 7 or Server 2008 prior to that.For more info on the symptoms and the work around, have a look at https://social.technet.microsoft.com/Forums/windowsserver/en-US/b8e58d83-3178-4490-b4f4-1c6e5542c39a/rdp-slow-initial-connection
Internal connections are fine but external users can’t connect.
By default, AADS will not accept remote connections from public IP addresses. Check the AADS firewall and tick the checkbox to allow connections from public IP addresses.
If this isn’t the case, check whether the forwarding on the router is configured to forward the correct port to the correct port and IP address on the LAN. When using port redirection for external connections, ensure to include the correct port in your connection setting on the client.
Some users can connect, others can’t.
The AADS firewall includes a mechanism to protect the server from remote attackers. By default, an IP address will be put on a block list for 7 days after 5 failed logons. Please make sure the IP addresses of those users who can’t connect are not on the “Temporary Block list”.
AADS connects, asks for a password and immediately disconnects.
You changed the “Terminal Server” port in the registry from 50xxx to the same port AADS is listening on. Since a fairly big redesign, AADS no longer sits “on top” of Windows’ own RDP functionality but “next” to it. As a result, the two are no longer sharing a common port to listen for connections. AADS automatically sets the RDP port to something in the 50xxx range. If you change it back, the two will be fighting over the port and both will lose.
The server is extremely slow, many users can’t connect and get disconnected frequently.
The most likely scenario: The machine is listening on port 3389 and the AADS firewall is disabled. DO NOT DO THIS! This configuration will not be supported. Please refer to the installation checklist.
AADS have implemented the firewall for a good reason and recommend keeping it enabled at all times. In fact, AADS will no longer provide support for machines which have the firewall disabled.
The other big “nono” this day and age is having the server listen on port 3389. Before you know it, you will have armies of bots knocking at your door trying to get in. To give you an idea, We have seen machines which had to deal with one inbound connection every 2 seconds. Besides this being a major security risk, it’s needless to say that this puts such a load on a machine that it can no longer function properly.
Our advice is to change the AADS listen port to something very different to 3389 and keep the AADS firewall enabled at all times. It uses barely any CPU time, is configured in 5 seconds flat but can be the difference between a great tool and a server which is no longer yours…
My server needs to listen on port 3389 but nobody can connect since I upgraded from an old version of AADS.
The problem is likely the Windows firewall. There is a predefined inbound rule for Remote Desktop connections, which deals with port 3389 traffic but this rule no longer works. The reason for this is simply that it isn’t a “port only” rule. If you have a close look at it, it is also linked to the application “System”. While this rule worked fine with older AADS builds but since the redesign, inbound connections are no longer for the application “System” and therefore not covered by this rule. Simply add a new “port only” rule for port 3389 and make sure it is enabled for all network types.