Shulou(Shulou.com)06/02 Report--

Sometimes in the work, the Exchange server will be blue after an unexpected restart and can not be recovered directly. After a month of stable operation through disaster recovery, the server is out of domain again. Here, I would like to summarize the process and ideas of dealing with the problem, hoping to be helpful to my peers.

Environment:

Operating system: Windows Server 2008 R2 sp1

Exchange version: Exchange2010sp3 CU8

Architecture: 3 CAS+4 sets of MBX

Symptom: one of the CAS servers (represented by CAS2) cannot enter the system after an unexpected restart. The test also failed to enter safe mode and be configured correctly for the last time.

Resolution process:

After confirming that it is not feasible to restore on the basis of the original system, it is decided to use reinstallation to restore.

According to the official Microsoft documents

Https://technet.microsoft.com/zh-cn/library/dd876880(v=exchg.141).aspx

The information provided is that the restore operation needs to meet the prerequisites:

The server performing the restore operation must be running the same operating system as the missing server

The server performing the restore operation must have the same performance characteristics and hardware configuration as the missing server

It runs on Exchange 2010 servers with client access, Hub Transport, Mailbox, or Unified messaging server roles installed.

The Exchange2010 environment of the customer does not have the role of edge server installed, which can fully meet the above conditions. In addition, when it can be determined, the path of the installation program on the original Exchange server is the default value, which makes the recovery process more convenient and does not need to specify a custom installation path.

Specific operation method: first reset the CAS2 computer account in AD > install the Server 2008 R2 sp1 system on the original physical machine and update the patch to be consistent with the other two CAS > modify the computer name to CAS2 > install the necessary components and then execute Setup / m:RecoverServer on the newly installed server.

The whole recovery process is quite smooth, and the OWA and outlook functions of the newly installed CAS2 can be used normally after the synchronization of user information is completed. Finally, add the new server to the NLB cluster. If you are using hardware load devices in your environment, you only need to enable the corresponding IP policy.

I thought it was over, but it was observed that the situation was good for two weeks, and there were no reports of mass users. On Monday, about a month later, a large number of users reported at work that the outlook pop-up window needed to enter a password and could not be used after entering the password. Immediately check whether the owa access of the three CAS is normal, just because the CAS2 cannot be used properly: the login interface can be popped up, and no further redirection can be made after entering the password. Unable to log in to the server using the mailbox administrator account, the local administrator can log in. Basic diagnosis was made immediately after landing:

The network configuration is normal and the network is smooth with DC and other Exchange servers.

System resources are normal: disk usage, CPU, and memory utilization are all within the normal range

Switching login prompts for other domain administrator accounts cannot establish a trust relationship.

To further confirm that it is delocalization, I tested the domain security channel trust relationship using nltest:

Nltest / server:servername / sc_query:domainname

The system prompts Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

In order to restore the business as soon as possible, we did not delve into the reasons for getting out of the domain but to restore the trust relationship. Usually the simplest way to deal with the client after delamination is to withdraw the domain and then readd the domain. The relatively simple way to judge whether it is normal is to check whether the network adapter is connected to the domain network. According to my experience, most of the computers that dedomain appear as public networks.

It is not convenient for mailbox servers to withdraw from the domain and re-add the domain to prevent the AD database from erasing some of the information specific to the Exchange server when withdrawing the domain. You need to use netdom tools to rebuild the trust relationship.

Run on an out-of-domain server

Netdom resetpwd / Server:dcname / ud:mailadminaccount / pd:password

There is no danger, the mailbox returned to normal after restart, but the whole process is step by step. A subsequent check of the Syslog attempts to confirm the reason why the server is out of domain, and no relevant information is found. Microsoft Forum for help and other resources to ask for help was fruitless and then no further research.

There are many factors that cause the server to go out of domain, such as computer duplicate name, long shutdown without communicating with the domain, or sid conflict.

[summary]

When there is a big condition that both failures can be recovered, the current customer environment is provided by 3CAS, and the configuration information can be synchronized from the normal server. One of the actions needed for both blue screen and dedomain recovery is to reset the computer account instead of deleting it directly. This is a key point, which can not only retain the original information, but also prevent the phenomenon that it can not enter the domain normally because of the SID inconsistency of computer name conflicts.

In addition, the way of command processing is more targeted for the diagnosis and recovery of the problem, and provides a more clear direction for locating the problem.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.