Sunday, February 24, 2013

An insight into Exchange 2013 Safety Net

Saftey Net is the new version of Transport Dumpster which was first introduced in Exchange 2007 and was continued in Exchange 2010.  I wrote about Transport Dumpster back in May 2011, please refer to the following blog post URL:

http://clintboessen.blogspot.com/2011/05/continuous-replication-block-mode-vs.html

However lets do a quick recap...

Transport Dumpster resides on all Hub Transport roles on both Exchange 2007/2010.  All messages which get delivered to users mailboxes is routed through a hub transport server and stored in Transport Dumpster.  In the event an email is sent from one user to another user on the same mailbox server, the mailbox server routes the email to a hub transport server and back again through MAPI.  This is to ensure that things such as journaling rules, transport rules and any other transport agents take effect, the message is filtered for malware/viruses (if configured), the message is trackable using message tracking logs and the message is copied in transport dumpster for a small period of time.

The following diagram shows what happens when Joe sent an email to Bob on the same mailbox server, the message goes to a hub transport server in the same AD site then back again to the mailbox server.



In Exchange 2010 the Transport Dumpster is controlled using the Set-TransportConfig cmdlet is configured to 15MB per database per default.  This means for every mailbox database the transport dumpster will always hold the last 15MB of email delivered to the  mailbox server.

What is the point?

In a database availability group (DAG) environment your active copy ships transaction logs to your passive copies.  What happens if suddenly your active mailbox server was to fail?  The passive copy may have not received the last transaction log, this will result in mail loss (assuming file mode replication is used).  After a mailbox database failover in a DAG environment, the new active copy will check for any non-replicated emails in the transport dumpster.  In the event it requires additional email, it will retrive the missing content from the dumpster.

Exchange 2013 Safety Net

Now that we have done a quick recap of Exchange Transport Dumpster which existed in Ex2010/2007 for DAG/CCR environments, lets look at whats new in Exchange 2013 Safety Net.

Unlike Transport Dumpster, Safety Net you cannot configure how many MB of messages to store, only how long you want to store messages with the default being 2 days.  This is because by setting a limit on the amount of data can result in data loss during a failover in the event a large amount of data had not replicated to the passive database copy.  Microsoft wanted to design Safety Net as a lossless solution hence this design change.

Message resubmissions from Safety Net are initiated by the Active Manager component of the Microsoft Exchange Replication service that manages DAGs and mailbox database copies. No manual actions are required to resubmit messages from Safety Net.

Safety Net is a queue that's associated with the Transport service on a Mailbox server. This queue stores copies of messages that were successfully processed by the server.  Safety Net uses the mail.que database, the same database which is used to store messages in queue.  As by default Safety Net will keep the last 2 days worth of email in this queue, expect the mail.que database to be larger then previous versions of Exchange.

The mail.que database file uses the Extensive Storage Engine (ESE), the same database technology which is used by the mailbox databases themselves.

Another improvement with Exchange 2013 Safety Net over Transport Dumpster is redundancy.  Safety Net itself is now redundant, and is no longer a single point of failure. This introduces the concept of the Primary Safety Net and the Shadow Safety Net. If the Primary Safety Net is unavailable for more than 12 hours, resubmit requests become shadow resubmit requests, and messages are re-delivered from the Shadow Safety Net.

With Safety Net being redundant, you can now feel confident in configuring the database mount dial setting to a more relaxed setting other then lossless and still feel confident that email will not be lost during failover.

Monday, February 18, 2013

msDS- Attributes in Active Directory

This is a short post to explain what msDS- attributes are in Active Directory.  As an administrator responsible for maintaining your companies Active Directory environment at some stage you have probably seen a bunch of msDS attributes linked to class objects such as user accounts.

What are msDS- attributes and how are they different to other attributes?

msDS- attributes are designed to hold data for Microsoft applications.  As best practice Microsoft recommends administrators never modify msDS- attributes as it can cause issues with applications.

Any attribute beginning with msDS- reference it, but do not modify it unless the changes is made through the application to avoid issues in your environment.

Tuesday, February 12, 2013

Group Policy Scripts in Windows Server 2008/2008R2/2012

With the release of Group Policy Management Console (GPMC) on server 2003, Group Policy had many sample scripts which were very handy when working with Group Policy.  These scripts included:

BackupAllGPOs.wsf
BackupGPO.wsf
CopyGPO.wsf
CreateEnvironmentFromXML.wsf
CreateGPO.wsf
CreateMigrationTable.wsf
CreateXMLFromEnvironment.wsf
DeleteGPO.wsf
DumpGPOInfo.wsf
DumpSOMInfo.wsf
FindDisabledGPOs.wsf
FindDuplicateNamedGPOs.wsf
FindGPOsByPolicyExtension.wsf
FindGPOsBySecurityGroup.wsf
FindGPOsWithNoSecurityFiltering.wsf
FindOrphanedGPOsInSYSVOL.wsf
FindSOMsWithExternalGPOLinks.wsf
FindUnlinkedGPOs.wsf
GetReportsForAllGPOs.wsf
GetReportsForGPO.wsf
GrantPermissionOnAllGPOs.wsf
ImportAllGPOs.wsf
ImportGPO.wsf
Lib_CommonGPMCFunctions.js
ListAllGPOs.wsf
ListSOMPolicyTree.wsf
QueryBackupLocation.wsf
RestoreAllGPOs.wsf
RestoreGPO.wsf
SampleEnvironment.xml
SampleMigrationTable.migtable
ScriptingReadme.rtf
SetGPOCreationPermissions.wsf
SetGPOPermissions.wsf
SetGPOPermissionsBySOM.wsf
SetSOMPermissions.wsf

These scripts are no longer packaged with Group Policy Management console in Server 2008/2008R2 or Server 2012.  Microsoft however has released these scripts for download to be used with any of the later versions of the Windows Operating system.  To download these scripts please view the following TechNet website:

http://www.microsoft.com/en-us/download/details.aspx?id=14536

Thursday, February 7, 2013

Converting Basic Disk to Dynamic Disk Stripped SMB Shares

We experienced a very interesting problem on a Windows Server 2003 file server in which all SMB shares were removed from the file server upon reboot.  We were in the process of moving a data volume from a Raw Device Mapping (RDM) to a VMDK virtual disk file in VMware.  To achieve this we were going to perform the following tasks within the virtual machine:
  1. Present a new VMDK to the Virtual Machine
  2. Convert the NTFS Volume from Basic to Dynamic
  3. Create a Software RAID1 Mirror between the RDM and VMDK volumes
  4. Allow for Windows Software Raid to replicate the data
  5. Remove the RAID1 Mirror for the RDM volume.
Upon converting the basic volume to a dynamic volume, Windows Server 2003 asked to reboot the server.  Upon reboot, all SMB shares on the file server automatically removed themselves.  There were hundreds of shares and as a result users could not get access to resources.

To recover the shares we simply restored the system registry which can be achieved through performing a system state restore.  Windows stores all SMB shares under the following location in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

We found the following Symantec article very helpful during this procedure:

http://www.symantec.com/business/support/index?page=content&id=TECH159845

Friday, February 1, 2013

Your computer can't connect to the remote computer because an error occurred on the remote computer that you want to connect to

I experienced an issue at a customer site with with a new Remote Desktop Services deployment on Windows Server 2008 R2 when building a Server Farm.
 
When Windows 7 PC's accessed a RemoteApp or attempted create a remote desktop session using the Microsoft Terminal Services Client (MSTSC.exe) they were able to connect to the farm without problems.
 
When an Windows XP PC accessed the remote desktop farm, the following error was experienced:
 
"Your computer can't connect to the remote computer because an error occurred on the remote computer that you want to connect to.  Contact your network administrator for assistance."
 

After researching the issue it turned out that the RD Session Hosts needed to be configured to use RDP Security as the Security Layer.  After installing a custom trusted certificate to the RDP-Tcp connection to ensure users connecting to the session hosts do not receive RDP Certificate not trusted warnings the issue started occuring.

These configuration options can be found under "Remote Desktop Session Host Configuration"

 
By default the Security layer was set to Negotiate.
 
Set all servers to RDP Security Layer in your farm to ensure both XP and Windows 7 clients can connect.