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.

While been extending and modifying my Exchange infrastructure, I was needed to duplicate Receive Connectors from one server to another. I wrote a simple template script for this task.

As you know, there are many types of Exchange 2013 logs, and a lot of disk space is used - and - space on system disk. Theoretically, you can change paths of all logs in Powershell. But because of number of logs types in Exchange, managing all these folders (and file sizes, directory sizes, max age of files) becomes a true nightmare.

Thus I created for me and you a little memo in Powershell scripts, so I can run them after installing of next new server.