Not so long ago I have rebooted one of my Windows 2008 R2 servers, and after that it no longer booted. I used I think all ways to boot it (Last known good configuration, Safe mode, Disable signed drivers check) - server everytime booted into Recovery mode.

Here is the list of commands that could help you in such cases.

The huge scalability of Microsoft Exchange carries serious disadvantages in addition to all its benefits. One of these cons - difficulties in message tracking from log files. Because of you have multiple transport servers, every message passing through every mailbox server and leave it's trail in logs.

Today I will try to at least partially help you in message tracking in Exchange 2013.

While I've been testing failover cluster of Microsoft SQL Server 2012 (more details: Step-by-step deploying AlwaysOn on MS SQL 2012) I was needed to generate mass import of some data into database.

As soon as I'm very bad in T-SQL, I decided to write script on Powershell for this task.

We will need:

• Database itself
• Table in it for testing purposes

Before Microsoft SQL Server 2012 and mechanism AlwaysOn were released, database administrators had only Database Mirroring as solution for replicating databases. It was the only option to get the "cheap" high availability. And Database Mirroring was not so good as it intended to be. Moreover, as my testings showed (and this is NOT written in documentation), it is NOT synchronous replication and transaction logs.

In short - we have studied the behavior of the database during intensive recording and different faults. What failures we saw:

• Planned shutdown of the master server (manual service stop) of the master server without any notification of the mirror server.
• Unplanned shutdown of the master server.

Oddly enough, it was a planned shutdown that showed that there is a difference between a mirrored database on the master and the mirror servers.

Therefore, I would not recommend to use Database Mirroring in production deployments, but take a look at the AlwaysOn technology.

Starting from version Exchange 2010, developers presented to us very good solution for high availability and fault tolerance of Mailbox Database Servers - Database Availability Group (DAG).

But situation was not so funny with high availability of Client Access Server in Exchange 2010. We had to create CAS-Arrays and NLB-clusters (based on Windows or hardware solutions).

Fortunately, in Exchange 2013 Microsoft gone forward to the brand new solution of providing client access to the service. Actually, now we have "former" Outlook Anywhere, which work for the clients from the Internet, as well as for the clients from the Intranet. Client requests to servers now processed independently of connection, i.e. now it's absolutely not important, which exactly CAS-server respond to the client, because all processings of requests are done at Mailbox servers, and CAS-servers just throw packets hither and thither .

Assume that you need to change service account for Microsoft SQL Server 2012 service. If earlier it was System, then now you need to work under some domain account.

Procedure itself of changing account is quite simple. Just start Sql Server Configuration Manager and in SQL Server Services subtree change properties of service.