{"id":3788,"date":"2019-07-26T06:15:34","date_gmt":"2019-07-26T06:15:34","guid":{"rendered":"https:\/\/www.kerneldatarecovery.com\/blog\/?p=3788"},"modified":"2022-12-07T10:39:43","modified_gmt":"2022-12-07T10:39:43","slug":"exchange-2010-server-access-denied-issues-emc-initialization-failed","status":"publish","type":"post","link":"https:\/\/www.kerneldatarecovery.com\/blog\/exchange-2010-server-access-denied-issues-emc-initialization-failed\/","title":{"rendered":"Exchange 2010 Server Access Denied Issues – EMC Initialization Failed"},"content":{"rendered":"

In the Exchange Server 2010, the user gets the Exchange Management Console to manage all the Exchange activities. It should start working as soon as the Exchange is installed on the Windows Server. But if it is not working even after a successful installation, you will need to start it manually.<\/p>\n

When the Exchange Management Console is not working, and you try to open it, then it shows the following error message –<\/p>\n

Initialization Filed<\/code><\/p>\n

You can go to the Server\u2019s Event log and check the details of the errors. One such detail is the following:
\n\"\"
\nThe error message indicates that the Exchange server ndrweb-exchang2<\/strong> is not a member of the Microsoft Exchange Security Groups. You can go to the Active Directory and check if the Exchange Server is present in the Members list. If not, then run the add-ExchangeServerGroupMember<\/strong> command at the Exchange Management Shell.<\/p>\n

When the Server is present in the Member list of Active Directory, then recheck the Event log and see for the possible error log.
\n\"\"
\nThe error description mentions that the clock settings of the client and server are not the same, and that is causing Kerberos authentication issues. You should check the time at the Server and domain controller for the client and if the time is different, then change them to sync.<\/p>\n

When the Exchange Server 2010 is installed on a different Hyper-V server than the domain controller, then there are chances that the time settings will differ from each other. You should uncheck the option of \u2018Time synchronization<\/strong>\u2019 and run the net time or set both Exchange Server and client to bring the time in the sync with their domain controllers.<\/p>\n

Finally, restart the Exchange Server and try to open the Exchange Management Console<\/strong> and it will start to function smoothly.<\/p>\n

Also, you can use the Remote Connectivity Analyzer verify the certificates, autodiscover, and several other features of the Exchange Server at any time to check if any other connectivity issues are there.<\/p>\n

Conclusion<\/h4>\n

Although Microsoft has released Exchange Server 2019, the latest version of Exchange Server, many users are still sticking to the Exchange Server 2010 and continue to work on it. But, if at any moment you want to upgrade to the latest version of Exchange, then it is a very challenging scenario for you as direct migration from on-premises Exchange Server 2010 to 2019 is not supported. You need to first migrate from Exchange 2010 to Exchange 2013 or Exchange server 2010 to 2016<\/a> and then migration from Exchange server 2013 or Exchange Server 2016 to Exchange Server 2019<\/a>.<\/p>\n

It is not a suitable method because you will need to purchase the license of an intermediator Exchange just for the migration. To overcome such a difficult condition, you can use Exchange Migrator<\/strong> software. It is an efficient Exchange Migration<\/a> tool specially developed for Exchange and Office 365 migrations. It can perform the migration for on-premises, online, hosted deployments of Exchange.<\/p>\n