Adaxes Q&A - Recent questions and answers in FAQ

What happens when Adaxes reaches end of service for a version?

Mon, 05 Jan 2026 08:51:44 +0000

Adaxes maintains support for:

The current version
The two previous versions

Once an Adaxes version falls outside of this window, it is considered to have reached the end of service.

End‑of‑service versions no longer receive updates, including bug fixes or security patches. Any third-party changes (for example, Microsoft updates) that disrupt Adaxes functionality will not be addressed after a version has reached the end of service.

While we won't deliver new updates for end‑of‑service versions, our support team will still assist you with configuration, troubleshooting, and general usage questions regardless of how old your version of Adaxes is.

How does Adaxes function after decommissioning the last Exchange server?

Thu, 30 Oct 2025 11:55:40 +0000

This article is relevant to you if your organization has fully transitioned to Exchange Online and decommissioned your last on-premises Exchange server.

Here are the most frequently asked questions and encountered issues.

How does Adaxes work with Exchange Management Tools (EMT)?

Adaxes does not use the Exchange Management Tools, and there is no setting to force it to do so.

Adaxes does not require EMT to manage mailboxes. Instead, Adaxes performs all necessary Exchange operations directly in the cloud using the Exchange Online PowerShell V3 module, provided your Microsoft 365 tenant is registered in Adaxes.

Why am I seeing errors when performing Exchange operations?

If you did not fully uninstall the last Exchange server but powered it off instead, Adaxes will treat your environment as having on-premises Exchange. This happens because the information about the last Exchange server is not removed from AD if it is not uninstalled.

You may see harmless error messages when performing certain Exchange operations on users with remote mailboxes. Adaxes performs the operation in Exchange Online, but also attempts to connect and run cmdlets against the missing on-premises server. The operation succeeds but you still see an error.

Also, actions exclusive to on-premises Exchange, such as Create mailbox and Mail-enable, will remain visible in Adaxes, even though they cannot be successfully executed. Attempts to execute them will always fail.

What should I configure in Adaxes?

To prevent unnecessary connection attempts to the missing server, specify your forest as one where Exchange is not managed by Adaxes. You will retain the ability to manage Exchange Online mailboxes as normal.

Leave remote mailbox settings, as is. Adaxes will not attempt to create remote mailboxes because you no longer need them. To provision mailboxes for new users, simply assign Exchange Online licenses to these users.

How does Adaxes determine account inactivity?

Tue, 23 Sep 2025 09:54:53 +0000

Some Adaxes features calculate how long a user or computer account has been inactive. For example:

The If is inactive <period> condition in business rules, scheduled tasks, and custom commands
The adm-InactivityDuration calculated property
The built-in Inactive users and Inactive users allowed to log in reports

Adaxes always uses the same calculation method. The inactivity duration of an account is measured since the most recent of the following events.

Account creation
Last sign-in
Last password change or reset

The dates of these events are pulled from specific properties, depending on whether the account is on-premises or in the cloud.

	Account creation	Last sign-in	Last password change
Active Directory	`whenCreated`	`lastLogon` `lastLogonTimestamp`	`pwdLastSet`
Entra ID	`createdDateTime`	`lastSignInDateTime` `lastNonInteractiveSignInDateTime`	`lastPasswordChangeDateTime`

For synchronized accounts in a hybrid environment, Adaxes checks for these events in both the on-premises and cloud accounts, and picks whichever date is the most recent.

Why does Adaxes read the ADFS DKM key and how to prevent it?

Fri, 28 Mar 2025 09:01:12 +0000

Issue

The Active Directory Federation Services (ADFS) master key that decrypts ADFS certificates is stored in Active Directory, in the thumbnailPhoto attribute of a contact object located in the CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=com container.

If the service account for your managed domain in Adaxes is a member of Domain Admins, it will have the rights to read the DKM master key. Note that Adaxes will never attempt to access the key on its own.

However, users that have the permissions to view contacts in Adaxes may be able to view the contact object where the DKM key is stored. This is especially true if you haven't modified or disabled the built-in Domain user security role that grants every user the rights to view every object in your directory via Adaxes.

Adaxes will not reveal the DKM key value under any circumstances, even if the user viewing the contact object has service administrator-level permissions. The attempt to view the contact will still trigger a Suspected AD FS DKM key read alert though.

Solution

It is recommended to deny the Read permission to your managed domain service account over the CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=com container via native AD access control.

How do I manage cloud-only users in Adaxes?

Thu, 16 Feb 2023 16:56:17 +0000

Starting from Adaxes 2023, you can manage Azure AD users, groups, and resource mailboxes that are not synchronized with an on-premises AD domain. However, having a registered Microsoft 365 tenant is not sufficient to view and manage cloud-only objects. You need to register your Azure AD domain. For details, see Register/unregister a managed domain.

It is also recommended to include the entire Azure AD domain in the scope of your Microsoft 365 tenant in Adaxes.

Why users cannot join computers to a domain in Adaxes if KB5020276 is installed?

Fri, 20 Jan 2023 12:22:12 +0000

If a computer has the KB5020276 Netjoin: Domain join hardening changes Windows update installed, you might encounter the following error message when attempting to join such a computer to a domain via Adaxes.

An account with the same name exists in Active Directory. Re-using the account was blocked by security policy.

The KB5020276 security patch imposes additional restrictions on who can join computers to a domain. As a result, if a computer account is created via Adaxes, the user specified in the Can be joined to domain by property of that account will not be able to join the computer to a domain unless one of the following scenarios is also true:

Scenario 1

The service account for the managed domain is a member of Domain Admins group.

Scenario 2

The computer in question has the following registry key set.

Path: HKLM\System\CurrentControlSet\Control\LSA
Type: REG_DWORD
Name: NetJoinLegacyAccountReuse
Value: 1

Scenario 3

The user who joins the computer to a domain is explicitly specified as the primary computer owner (specified in the ManagedBy (Primary) property).

‎ ‎

How to hide the message about the temporary Microsoft 365 password assignment in the execution log?

Wed, 16 Nov 2022 11:22:52 +0000

By default, in hybrid environments, when an on-premises AD object is created in Adaxes within the scope of a Microsoft 365 tenant, Adaxes will create the corresponding object in Azure AD.

If Adaxes is configured not to synchronize passwords or a password specified for a new user does not meet password policy requirements in Azure AD, a random temporary password will be generated for that user. By default, the following message with the generated password will be displayed in the execution log:

A temporary password has been assigned to the user's Microsoft 365 account. The temporary password is \.

To configure Adaxes not to display this message:

Launch Adaxes Administration console.
In the Console Tree, expand the Adaxes service node.
Navigate to Configuration / Cloud Services and select Microsoft 365.
In the Result Pane on the right, select your Microsoft 365 tenant and click Edit.
On the Tenant Details tab, click More options.
Clear the Display the temporary password in the Execution Log checkbox.
Click OK twice.

How are Web interface language and date format selected?

Wed, 10 Feb 2021 15:41:15 +0000

The language of Adaxes Web interface and the format used to display dates can be different depending on the signed in user. The language can be selected either automatically or manually, whereas the regional format is always selected automatically.

Language

Each user can manually choose the language of Adaxes Web interface. If a user selects a language manually, the choice is saved in their personal settings and the Web interface is always displayed for them in that language, regardless of the browser and the computer regional settings.

Alternatively, users can let Adaxes automatically select their Web interface language each time they sign in. In this case, Adaxes will select the language based on the list of languages of the user's web browser. If none of the languages from the list match a language Adaxes is available in, English (en-US) will be selected by default. This means that for the same user, a different Web interface language can be selected each time they sign in, depending on the browser language settings.

Regional format

The format for displaying dates is selected based on the Web Interface language. If the language has multiple regional formats e.g. English (United Kingdom) and English (United States), the format is selected based on the language settings set in the user's browser.

For example, if the user selected English as their Web interface language, and English (United Kingdom) is present in their browser language list, the dates will be displayed in the en-GB regional format (DD/MM/YYYY). On the other hand, if the user has English (United States) in their browser language list, the dates will be displayed in the en-US regional format (MM/DD/YYYY). Finally, if the user doesn't have English in their browser language list, the default regional format will be used. For the built-in languages, the default formats are: en-US for English, fr for French, and de for German.

Can I remove the Adaxes part from Web Interface URLs?

Wed, 30 Oct 2019 09:40:35 +0000

By default, Web Interface URLs look like the following: http://host.company.com/Adaxes/HelpDesk. For the URLs not to contain the Adaxes part:

On the computer where Adaxes Web Interface is installed, launch Internet Information Services (IIS) Manager.
In the Connections pane, expand the server that hosts Adaxes Web Interface and then expand Sites.
Select the web site that hosts Adaxes Web Interface and click Advanced Settings in the Actions pane on the right.
Expand the General section.
In the Physical Path field, enter the path to the App subfolder of the folder where Adaxes Web Interface is installed which is C:\Program Files\Softerra\Adaxes 3\Web Interface by default.
Click OK.
Restart IIS.

How do I redirect the default web site to the Common Sign In page?

Wed, 30 Oct 2019 09:37:41 +0000

This can be setup using the HTTP Redirect option in IIS:

On the computer where Adaxes Web Interface is installed, launch Internet Information Services (IIS) Manager.
In the Connections pane, expand the server that hosts Adaxes Web Interface and then expand Sites.
Select the web site that hosts Adaxes Web Interface.
In the Home pane on the right, double-click HTTP Redirect.
Select the Redirect requests to this destination checkbox.
In the field below, enter the URL of the Common Sign In page (e.g. http://webserver.company.com/Adaxes).
Clear the Redirect all requests to exact destination (instead of relative to destination) checkbox.
Select Only redirect requests to content in this directory (not subdirectories).
In the Status code drop-down, select Permanent (301).
In the Actions pane on the right, click Apply.
Restart IIS.

How do I reset an authenticator app for a user?

Mon, 28 Oct 2019 13:55:08 +0000

An authenticator app can be reset for a user with the help of the Reset multifactor authentication operation in Adaxes Web Interface or Administration Console. In the Web Interface, users can also use the Change device option. For details, see Reset Authenticator App.

How to unregister an Adaxes service manually?

Thu, 23 Aug 2012 16:54:40 +0000

Sometimes, if an Adaxes service was not uninstalled properly, Adaxes Administration Console shows the removed instance in the list of available Adaxes services.

The easiest way to clear the registration information is to install Adaxes service on the same computer again, register all the domains you previously managed, and uninstall the service. If you cannot do this, read the rest of this article.

Information about available Adaxes services is stored in Active Directory. To publish the information, Adaxes uses service connection points (SCPs). To clear the registration information, you need to delete appropriate SCP entries in Active Directory:

Launch Adaxes Administration console.
In the Console Tree, expand your Adaxes service node, right-click Managed Domains, and then click Find.
In the Find dialog, activate the Criteria tab.
Copy the following JSON criteria to the clipboard.

{
    "objectTypes": [
        {
        "type": "serviceConnectionPoint",
        "items": {
            "type": 1,
            "items": [
            {
                "type": 0,
                "property": "keywords",
                "operator": "eq",
                "values": [{ "type": 2, "value": "1.3.6.1.4.1.15741.2.3.1" }],
                "valueLogicalOperator": 0
            }
            ],
            "logicalOperator": 1
        }
        }
    ]
}

Click Add criteria, and in the drop-down menu click Paste.
Click Search. Adaxes will search for all the SCPs of Adaxes services in all managed Active Directory domains.
Delete the SCP entries that were published by a removed Adaxes service.

What ports does Adaxes use?

Thu, 18 Nov 2010 09:51:43 +0000

Adaxes Service

To enable communication between Adaxes service and Active Directory, the following ports (TCP and UDP) must be open for outgoing connections on the computer where your Adaxes service is installed, and for incoming connections on the Domain Controller(s) that you want Adaxes to connect to.

389 LDAP - to connect to Active Directory
636 LDAP (SSL) - to connect to Active Directory via SSL
3268 LDAP - to connect to AD Global Catalog
3269 LDAP (SSL) - to connect to AD Global Catalog via SSL
88 Kerberos - for authentication
135 RPC - to resolve AD user names
Dynamic RPC ports* - to communicate with Active Directory

Additionally, to allow communication between Adaxes service and your Exchange Servers, you need to open the following ports:

80 HTTP - if Adaxes service and Exchange are installed in the same forest
443 HTTPS - if Adaxes service and Exchange are installed in different forests

Also, you need to allow Adaxes service to ping Active Directory domain controllers. To do this, enable Echo ICMP Requests (ping) in the firewall settings.

Adaxes Clients

Adaxes Web Interface, REST API, and Adaxes Administration Console use the following ports (TCP and UDP):

389 LDAP - to connect to Active Directory
54782 - for communication with the Adaxes service

If Adaxes clients are deployed in the perimeter network (DMZ), only the 54782 port needs to be opened in the firewall for communication between Adaxes clients in the DMZ and Adaxes service on the intranet.

If an Adaxes client is deployed in a domain that is:

Not managed by Adaxes service and
Different from the domain where Adaxes service is deployed,

then you also need to open the 3268 port on the computer where that Adaxes client is installed. It will be used to connect to AD Global Catalog to locate the Adaxes service.

It is possible to change the port used for communication between Adaxes service and Adaxes clients (Web Interface and Administration console). For this purpose you need to change the port attribute of the following XML element of the Adaxes service configuration file (Softerra.Adaxes.Service.exe.Config):

<configuration>
  ...
    <system.runtime.remoting>
    <customErrors mode="Off" />
    <application>
      <channels>
        <channel ref="tcp" port="54782" priority="2" secure="true">

The Softerra.Adaxes.Service.exe.Config file is located in the folder where the Adaxes Service is installed (by default, C:\Program Files\Softerra\Adaxes 3\Service).

* To enable communication through dynamic RPC ports:

Open the full range of dynamic RPC ports (1024-5000 for Windows 2003, 49152-65535 for Windows 2008 and higher).
OR
On Windows Server 2008 or higher, you can configure the Windows firewall to open RPC ports dynamically. If you do this there is no need to open a port range for dynamic RPC. For details, see Allowing Inbound Network Traffic that Uses Dynamic RPC.
OR
Explicitly specify which RPC port must be used by Active Directory, and open that port. For details, see Restricting Active Directory replication traffic and client RPC traffic to a specific port

Can I configure Adaxes Web Interface to use SSL?

Thu, 14 Oct 2010 13:00:03 +0000

By default, SSL is not configured for the Adaxes Web Interface and network transmissions are not encrypted. However, you can configure SSL on the Adaxes Web Interface the way you do it for any other website hosted by IIS. If you configure SSL on the Adaxes Web Interface, it will work in both cases: with Windows-integrated authentication and with forms-based authentication.

How Adaxes communicates with AD? Is the connection secured?

Thu, 14 Oct 2010 12:58:45 +0000

Adaxes service uses the LDAP protocol to communicate with Active Directory. Interaction between the Adaxes service and Active Directory is secured for security-sensitive operations only. For example, prior to change or reset a password for an AD user, an SSL connection is established and the data are sent via an encrypted channel.

Interaction between Adaxes clients and Adaxes services is always performed using an encrypted TCP channel.

Where does Adaxes store credentials?

Thu, 14 Oct 2010 12:50:29 +0000

Adaxes service account

Adaxes itself doesn't store the password for the Adaxes service account. Adaxes service is installed as a Windows system service that runs under the Adaxes service account. Credentials for the system service are provided during installation and are stored by Windows.

Other credentials

Credentials for managed domains
Credentials for Microsoft 365 tenants
Credentials for external MS SQL logging database
Credentials used in mail settings
Credentials used to run PowerShell scripts (Run As)

Adaxes stores the above credentials in AD LDS on the computer where the Adaxes service is installed. The stored credentials are encrypted with an AES-256 master key. The master key is encrypted using RSA-2048 and is also stored in AD LDS. The private RSA key that can decrypt the master key is stored locally on the computer where the Adaxes service is installed and is never transferred over the network. The key is encrypted using the Data Protection API (DPAPI) provided by Windows and can be accessed only by the Adaxes service account. To read the stored credentials, the Adaxes service decrypts its private key with the credentials of the Adaxes service account, uses the private key to decrypt the master key, and, finally, uses the master key to decrypt the stored credentials. All the encryption keys are renewed every 14 days.

As the master key is required to decrypt the credentials, it must be securely exchanged between Adaxes services in a multi-server environment. To do this, the master key is encrypted separately for each Adaxes service using RSA. Here is how.

When the first Adaxes service is installed, it generates the master key and a public-private key pair. The public key is published to AD LDS and the private key is stored locally. The Adaxes service then uses its own public key to encrypt the master key, and stores the encrypted master key in AD LDS. When a new Adaxes service instance is added to the configuration set, it generates its own public-private key pair and publishes the public key to AD LDS. Adaxes can recognize that a legitimate service instance is being installed using the AD LDS metadata – the information about the new service instance can be added only by AD LDS and only during Adaxes installation. Moreover, the metadata can be accessed only by the Adaxes service account.

When Adaxes detects that a new service instance is added, it encypts the master key for the new service instance with its public key, and stores the encrypted master key in AD LDS. As a result, AD LDS will contain multiple copies of the master key, each encrypted with a different public key of the corresponding Adaxes service. Each service instance can access its copy of the master key and decrypt it locally with its own private key.

Does Softerra Adaxes extend the Active Directory schema?

Wed, 17 Jun 2009 15:39:19 +0000

Softerra Adaxes does not extend the AD schema. Moreover, Softerra Adaxes does not store its data in Active Directory and doesn't modify the native permissions assigned in AD. If you uninstall Softerra Adaxes, you can use Active Directory just as you did before the product installation.

Do I have to create a trust between two domains to manage them with the same Adaxes service?

Wed, 29 Apr 2009 12:04:43 +0000

You do not need to create a trust between AD domains to manage them with an Adaxes service. When registering an AD domain, an account with administrative permissions is specified. All operations performed via the Adaxes service in this AD domain are executed using this account. To control the user access to the managed resources, the Adaxes service uses Security Roles.

How can I update multiple user accounts at once?

Tue, 28 Apr 2009 08:43:38 +0000

Using the Adaxes Administration Console, you can perform bulk update of AD users in several ways:

Using the Add or Modify Property Wizard:

Select the AD users you need in the Result Pane, Basket or search results.
Right-click the selected users and click Add/Modify Property in the context menu.
Modify properties of the selected users the way you need.

Using the Property Pages:

Select the AD users you need in the Result Pane, Basket or search results.
Right-click the selected users and select Properties from the context menu.
In the Multiple Selection Properties dialog box, select the check box for the property you want to change and specify a new value for this property.
Click OK.

You can also delete or move multiple AD objects, enable or disable multiple user and computer accounts, add users or contacts to a group in bulk, etc.