Windows Server 2012 Deduplication

Tonight I am playing with the new Windows Server 2012 RTM which I have downloaded and installed in a virtual environment. One of the new features which I like in Windows Server 2012 is the File Storage deduplication option. No longer do customers need to purchase expensive 3rd party deduplication software - Microsoft allows customers to perform deduplication of there data for free witht he purchase of a Windows Server 2012 license.

Below is a screenshot of where you enable the deduplication feature in the new Windows Server 2012 server manager console.

Introducing Exchange Online Protection (EOP)

If you have yet to hear, Microsoft has retired their entire Forefront product suite.  For products which will continue such as Forefront Identity Manager, these products have been moved to the System Center product suite.

As part of this move to remove the Forefront product family, Forefront protection for Exchange (FPE) and Forefront Online Protection for Exchange (FOPE) are also being removed.
Forefront Protection for Exchange (FOPE) is being replaced with a new product called Exchange Online Protection (EOP).  When I say new, it is actually the next release of FOPE.  Exchange Online Protection is an online Microsoft cloud service for filtering email.  It can be implemented for both cloud based Exchange customers such as Office 365 as well as on-premises implementations of Exchange.

In terms of Forefront Protection for Exchange (FPE), a product which is installed on a Windows server in the customers environment - there is no replacement I'm currently aware of.  Apart from the integrated spam filtering functionality which comes as part of Microsoft Exchange, Microsoft do not offer an on-premises product which customers can install for filtering email spam.  Customers will be encouraged moving forward to adopt Microsoft's online cloud services for filtering spam which can be found under EOP.

Exchange Online Protection offers customers the following functionality:

• URL lists for spam filtering that block messages containing specific URLs within their message body. EOP includes additional lists beyond those available in FOPE.
• The ability to skip spam filtering for trusted senders, based on subscription lists
• The ability to filter messages written in specific languages, or sent from specific countries or regions
• Malware filtering that can delete and strip unsafe attachments
• The capacity to mark bulk email (such as advertisements) as spam through the user interface
• The capability to search for, view, or release quarantined email messages in the EAC
• Transport rules which you can use to control mail flow, based on a message’s content
• Message tracing capability, which allows you to search for and view details about a specific message
• Inbound connectors and outbound connectors you can use to enforce secure communication between you and a partner, or to make hybrid mail flow (where you host a portion of your mailboxes on-premises and a portion in the cloud) possible New reports, which you can use to monitor your organization’s mail flow, available in the Office 365 portal, by using a Microsoft Excel download application, or by using a Web service.

Previously FOPE had a seperate user interface to Office 365 for users to manage spam settings.  Microsoft has now consolidated this under the new Exchange Administrative Center (EAC).  For Exchange Online (Office 365) customers, EOP has now been intergrated directly into the EAC console, however for on-premises customers users will still need to go to another web address to access the online EAC for configuring Exchange Online Protection.

 

Below is a screenshot of the configuation interface for Exchange Online Protection (EOP):

 

 

Removing the requirement to specify domain name with Single Signon for Remote Desktop Services

Windows 2008 R2 Remote Desktop Services single signon provides the users the ability to login to RD Web Access and launch applications without having to provide login credentials twice.  While single sign on is great it does not just work out of the box, there are a few things you need to do to configure single sign on.  These steps are documented on the following blog post:

http://blogs.msdn.com/b/rds/archive/2009/08/11/introducing-web-single-sign-on-for-remoteapp-and-desktop-connections.aspx

What is not documented however is for single sign on to work by default, users must login with:

DOMAIN\Username

For example:

If a user logs in with just the user name such bugs.bunny as show in the screenshot below, when the user enters the RD Web Access and attempts to launch a remote application the user will receive the error below.

 

Error experienced:

Your computer can't connect to the remote computer because an error occured on the remote computer that you want to connect to.  Contact your network administrator for assistance.

Note: This error message is generic and is presented for a wide range of problems relating to RDS.

For my this Active Directory we want users to login by simply entering their username, we do not want users to have to specify their domain name.  To do this perform the following procedure:

 

1.     Login to the Remote Desktop Web Access role-based server with local/Domain administrative permissions.

2.     Navigate to the following location:

 %windir%\Web\RDWeb\Pages\The Language of Your Location\

3.     Backup the login.aspx file to another location.

4.     Right click the login.aspx file, and select Edit. The file will be opened with Edit status in your default HTML editor.

5.     Change the original code section:

input id=”DomainUserName” name=”DomainUserName” type=”text” class=”textInputField” runat=”server” size=”25” autocomplete=”off” /

to be:

input id=”DomainUserName” name=”DomainUserName” type=”text” class=”textInputField” runat=”server” size=”25” autocomplete=”off” value=”domainname\” /

 

6.     Save the modification.

Now when users access the RD Web Access portal the username field will already be populated with domainname\

 

Exchange 2010 Randomly Loosing Access to Active Directory

I had an issue at a customer site where a vitalised multi role Exchange 2010 server was randomly loosing access to Active Directory.  There were two Active Directory Domain Controllers with the Global Catalog role in the same Active Directory site as the Exchange 2010 server with highspeed 1gbps LAN between the servers.

When the issue occured Exchange 2010 would begin spitting the generic errors you receive whenever there is no Active Directory domain controller available.  Some of these errors include:

Log Name:      Application
Source:        MSExchange ADAccess
Date:          13/08/2012 8:58:37 AM
Event ID:      2114
Task Category: Topology
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Exchange2010.domain.local
Description:
Process STORE.EXE (PID=3788). Topology discovery failed, error 0x80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message)). Look up the Lightweight Directory Access Protocol (LDAP) error code specified in the event description. To do this, use Microsoft Knowledge Base article 218185, "Microsoft LDAP Error Codes." Use the information in that article to learn more about the cause and resolution to this error. Use the Ping or PathPing command-line tools to test network connectivity to local domain controllers.

Log Name:      Application
Source:        MSExchange ADAccess
Date:          13/08/2012 9:01:56 AM
Event ID:      2103
Task Category: Topology
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Exchange2010.domain.local
Description:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1468). All Global Catalog Servers in forest DC=internal,DC=domain,DC=com are not responding:
DC1.domain.local
DC2.domain.local

Log Name:      Application
Source:        MSExchange ADAccess
Date:          13/08/2012 9:04:56 AM
Event ID:      2604
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Exchange2010.domain.local
Description:
Process MSEXCHANGEADTOPOLOGY (PID=1468). When updating security for a remote procedure call (RPC) access for the Microsoft Exchange Active Directory Topology service, Exchange could not retrieve the security descriptor for Exchange server object Exchange2010 - Error code=80040934.
 The Microsoft Exchange Active Directory Topology service will continue starting with limited permissions.

Log Name:      Application
Source:        MSExchange ADAccess
Date:          13/08/2012 9:07:56 AM
Event ID:      2501
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Exchange2010.domain.local
Description:
Process MSEXCHANGEADTOPOLOGY (PID=1468). The site monitor API was unable to verify the site name for this Exchange computer - Call=HrSearch Error code=80040934. Make sure that Exchange server is correctly registered on the DNS server.

 

When this issue was occuring I verified that the Exchange 2010 server was successfully talking to a domain controller in the same Active Directory site by issuing the following command from a command prompt:

 

NLTEST /DSGETDC:domain.local

 

The problem was with the Exchange 2010 application itself randomly loosing access to Active Directory.

 

After further diagnosing I made the following changes to the Windows TCP Network stack on the Exchange2010 server:

 

netsh int tcp set global chimney=disabled

netsh int tcp set global rss=disabled

netsh int tcp set global taskoffload=disabled

netsh int tcp set global autotuninglevel=disabled

 

 

This resolved the problem.

Only run these commands on your Exchange 2010 server if you are sure that there is a Active Directory Domain Controller in the same Active Directory site as your Exchange 2010 server and the Exchange 2010 server is able to communicate with the Active Directory domain controller.  Ensure you diagnose all other possible resolutions first such as network/storage/cpu/memory bottlenecks.

Hope this post has been helpful.

Reset Backup Exec 2012 to Factory Defaults

Symantec has published an article on how to restore Backup Exec to factory defaults using BEUtility.exe however this article only works for  Backup Exec 11D/12.0/12.5/2010/2010R2/2010R3.  This article can be found here:

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

When trying to perform this procedure on Backup Exec 2012 it fails with the following error message:

Error: Unable to drop database

This is a bug with Backup Exec 2012 however there is a work around, to restore the Database to Factory Defaults perform the following procedure:

1. Stop all backup exec services.

2. Go to C:\program files\symantec\backup exec\data

3. Rename the current database file bedb_dat.mdf to something else.

4. Rename the current log file database  bedb_log.ldf to something else

5. Now use bedb_dat.bak file and rename it to bedb_dat.mdf

6. Now use the bedb_log.bak file and rename it to bedb_log.ldf

7. Now restart all backup exec services.

View Mailbox Sizes for Exchange 2003 and Exchange 2010 through Powershell

If you need to view mailbox sizes for users in your Exchange organisation, you can do this from an Exchange Management Shell (EMS) for both Exchange 2003 and Exchange 2007/2010.

For your Exchange 2007/2010 users use the following command from EMS:

get-mailboxstatistics | fl displayname,totalitemsize

For your Exchange 2003 users use the following command from EMS:

Get-Wmiobject -namespace root\MicrosoftExchangeV2 -class exchange_mailbox -computer Ex2003ServerName | sort -desc size | select storageGroupName,StoreName,MailboxDisplayName,Size,TotalItems

Microsoft Axes the Forefront Product Suite

Today, Microsoft has announced that the Forefront product suite is no longer being continued.  Gartner started the rumours quite some time ago claiming that Microsoft was no longer going to continue Threat Management Gateway, however who would have thought this was to extend to the entire Forefront product suite.

Please read the following article by Forefront TMG MVP, Richard Hicks:

http://tmgblog.richardhicks.com/2012/09/12/forefront-tmg-2010-end-of-life-statement/

For the official annoucement from Microsoft please see:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Outlook can finally deal with Passwords Expiring

Outlook has never had the ability to deal with passwords expiring, until now!  The Microsoft Outlook team has released updates for Outlook 2010 and 2007 that provide Office 365 users with password expiration notifications. The advance password expiry notification will be displayed in a pop-up message (near the system clock) within a certain time period before their password actually expires. That time period is configurable by the tenant admin (see links below for more info). For users whose passwords have already expired, Outlook will flash an error message when users try to connect to their mailbox. In both scenarios, Outlook also provides a link (URL) to update passwords via the browser. When users click on those links, they are taken to the Microsoft Online Portal to change/update their passwords.

Very cool!

The knowledge base article for this update can be found under the KB2745588

Windows Server 2012 IIS8 Server Name Indication

A new version of Windows Server is about to become upon us, Windows Server 2012 and with this a new version of Internet Information Services (IIS), version 8.  IIS8 comes with a new cool feature called Server Name Indication (SNI).

In pervious versions of 5, 6, 7, 7.5 etc we have always had the ability to host multiple web sites under same IP address/port using HTTP/1.1 virtual hosting, i.e."Host Headers" where the web server looks at the DNS address entered into the Internet Browser and forwards the user to the appropriate site.  Of course if a user accesses a website by IP, the Host Header will not work.

IIS has supported utilising Host Headers for HTTPS sites also for quite some time, however this has always been harder to configure with manual editing of the IIS metabase being required in previous versions of IIS, see http://clintboessen.blogspot.com.au/2009/03/how-to-setup-ssl-host-headers-iis6.html.  However although SSL Host Headers were supported there was one problem which administrators faced.  There was no way to sign a different digital certificate for each HTTPS website.

Now with IIS8 in Windows Server 2012, a new feature has been added tha extends the SSL and TLS protocols to indicate what hostname the client is attempting to connect to at the start of the handshaking process.  This allows the IIS8 server to present multiple certificates on the same IP address and port number and hence allows multiple secure (HTTPS) websites to be served off the same IP address without requiring all those sites to use the same certificate.  Multiple digital certificates assigned to the same the same IP/Port - very cool.

I'm sure we will see many changes to applications which leverage IIS adopting this new technology.

Internal Names and Public Certificates

I have just found out today that internal domain names are no longer supported on public certificates.  Please view the following article by DigiCert.

http://www.digicert.com/internal-names.htm

For Exchange this is going to increase the requirement for split DNS within organisations to ensure customers can use the same address for both the Internal and External URLs.  However there are examples which I can see as being a problem moving forward.

When setting up a Remote Desktop Gateway server (for RDP over HTTPS) you need two public certificates, or one certificate with multiple subject alternative names. One public certificate will terminate the SSL endpoint of the RD Gateway server such as "rdpgateway.example.com" and is enabled within Internet Information Services.  The second certificate requires the internal name of the Remote Desktop Session Hosts or Terminal Servers to ensure the RDP traffic is digitally signed such as "terminalserver01.domain.local". This server certificate needs to be installed on the terminal server(s) themselves with the name matching the internal FQDN of the server(s).  Most companies do not install digital certificates to sign RDP traffic, instead they leave the default self-signed certificate on the servers (which does not show up in the local MMC certificates store).  This is why you always see the following warning when initiating remote desktop to a server:

Now we could use an internal certificate authority to issue the certificates for our RD Session Hosts, however this would require that all computers who access the RD Farm to be on the Active Directory domain to ensure they trust the internal certificate authority.  What about if there are users who are connecting in from machines that are not a member of the Active Directory domain?  One of my clients develops an application and sells the application by presenting it to clients as a RemoteApp meaning computers all over the world are launching this application.  Without having a public certificate containing internal names, my customers would receive warnings relating to the RDP traffic being untrusted.

I spoke to a representative from DigiCert about this today, and I ran this example past him.  The advise he presented to me was to rename the Active Directory forest to "local.example.com" to ensure the domain ended with a dot com.  I do not see this as practical especially for large Active Directory domains which consist of thousands of users.

I wonder what other headaches these changes to the certificate standard will present for IT professionals around the world.

Please feel free to leave your comments on the matter.

The Limit for Outlook OST Files

How big can your Outlook OST file grow for cached Exchange mode?  Well the answer to this is BIG.  Outlook 2003/2007 out of the box has a 20GB limit on OST files, while Outlook 2010 has a 50GB limit on OST files.

This is documented by Microsoft on the following KB article:

http://support.microsoft.com/kb/832925

Whilst these limits have been put in place they can be extended by modifying the MaxLargeFileSize DWORD registry value located under the following location:

Outlook 2010

The policy location for the registry entries is located in the following path in Registry Editor:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\PST

The user preference location for the registry entries is located in the following path in Registry Editor:

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\PST

Outlook 2007

The policy location for the registry entries is located in the following path in Registry Editor:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\PST

The user preference location for the registry entries is located in the following path in Registry Editor:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\PST

Outlook 2003

The policy location for the registry entries is located in the following path in Registry Editor:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook\PST

The user preference location for the registry entries is located in the following path in Registry Editor:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\PST

So whats this harp about PST files and OST files limited to 2GB in size?  ANSI (the format previously used for OST/PST files) is limited to 2GB in size - and it does not handle hitting this limit very well.

The new format which is used is Unicode - the actual Unicode limit is unknown.  We do believe it is in the TB, perhaps around 4 TB, but we have never tested (nor have we ever been able to test) to find the limit for performance reasons.

Move Messages to Another Working Queue

In the event a Hub Transport server is completely out, you may have the requirement to move all messages in a queue to another Hub Transport server in your organisation to ensure the messages are delivered.  How can you do this?

First you need to export all messages in the current queue.  You can do this with the following powershell commands:

$array = @(Get-Message -Queue "QueueName" -ResultSize unlimited)

$array | ForEach-Object {$i++;Export-Message $_.Identity | AssembleMessage -Path ("c:\MailsExport\"+ $i +".eml")}

To import the messages into the new Hub Transport server, simply place the .eml files into the Transport Pickup folder.  The new server should immediately start processing the messages.

An insight into OWA Desktop by Messageware

In this article we will be looking at a product called OWA Desktop by Messageware.

What is OWA Desktop?

OWA Desktop provides users with an email client without having to install Microsoft Outlook.  It enhances the functionality of Outlook Web App 2010 or Outlook Web Access 2007 resolving many of the limitations which prevent OWA being used as a full blown email client.

OWA by itself has a number of problems when being used as an email client.  It runs in an internet browser and requires constant user interaction to ensure it does not sign the users session out.  Another problem with OWA is there is nothing stopping a user from accidentally closing the internet browser running their OWA session.

OWA Desktop is a light weight application written in Microsoft .Net Framework 3.5 SP1 which runs in the background on a users workstation providing them with a constant connection to Microsoft OWA.  It provides alerts, notifications, email, calendar and tasks access on the fly as you would get out of Microsoft Outlook all from an easy to use OWA Interface.

OWA Desktop runs on the following operating systems:

• Windows XP
• Windows Vista
• Windows 7
• Windows 8
• Windows Server 2003
• Windows Server 2008
• Windows Server 2008 R2
• Windows Server 2012

OWA Desktop currently supports the following version of Exchange:

Exchange 2007

Exchange 2010

Office 365

OWA Desktop utilises a combination of Exchange Web Services and Outlook Web App to interact with the Exchange 2007/2010 servers.  OWA Desktop will support Exchange 2013, however this is still in development.

When would you want to deploy OWA Desktop?

Not all users require programs such as word processors and spreadsheet applications to perform their daily job.  Some users may only require an email client and it doesnt make sense to deploy the entire Microsoft Office suite.  Microsoft Office is a serious investment which needs to be factored into any IT budget.  There is a gap which needs to be filled to provide companies a cheap alternative for a desktop email client.  Messageware have filled this much needed gap with OWA Desktop providing companies the ability to deploy an email client to users at a cost of around $1.50 EURO a user per month.  Pricing is subject to change and depends on the number of users licenses purchased but regardless it is a significant cost saving over the purchase of Microsoft Oulook.  To get a quote for your organisation contact SalesTeam@messageware.com.
Running OWA Desktop for end users provides additional cost savings other then just licensing.  It also provides a reduction in IT operational expenses.  Deploying Microsoft Office to users means that Microsoft Office needs to be maintained.  Administrators need to deploy critical security updates and patches to Microsoft Office to ensure security vulnerabilities in the application are not exposed.  Products such as Symantec Altiris, Microsoft System Center Configuration Manager (SCCM) or Windows Software Update Services (WSUS) must be put in place to maintain various industry security compliance's such as CIS or NIST to patch security vulnerabilities in Office when discovered.  When running OWA Desktop, all content displayed within OWA Desktop is generated from the Exchange server through OWA and Exchange EWS.  Administrators no longer need to worry about patching and maintaining Microsoft Office.

OWA Desktop In Action

OWA Desktop is very easy to configure, it supports autodiscover and only requires a few details to get started.

Once setup OWA Desktop sits in your system tray.  Any incoming emails, meeting requests or appointments popup in the bottom left the users screen as it would in Microsoft Outlook.  It remains logged in and will automatically reconnect should disruption to OWA services occur.  OWA Desktop can also be configured to automatically load with Windows to ensure users never miss an email.

When right clicking on OWA Desktop the application menu appears.  Users can open their inbox, calendar, tasks or compose a new email message at the click of a button.  Compared to the number of clicks required to open a new browser, login to OWA, and click the new compose button it makes utilising OWA as a desktop email client simple, easy and hassle free.



The following screenshot shows the Inbox screen of OWA Desktop.



The following screen shows composing a new email via OWA Desktop.

It is OWA as you know it, simple, fast, easy to use in a desktop environment!

Messageware Active Send

Another component of OWA Desktop which is installed seperately using a seperate MSI file is Messageware Active Send.  This incorporates the send to mail functionality of the Windows operating system with OWA associating OWA as an application.  When a user right clicks a file, navigates to Send To and selects Mail recipient, Messageware Active Send will automatically upload the file into Exchange 2010 OWA and open the file as an attachment to a new email message in OWA - very cool.  This also works with any "mailto:" hyperlinks which may appear within documents, email messages or web pages.




Deployment

Both OWA Desktop and Active Send are MSI files which can be deployed to workstations on mass through group policy software deployment or another application such as SCCM or Symanted Altiris.

Conclusion

OWA Desktop is a great low cost application for users who do not require the full Microsoft Office product suite.

RemoteApps do not appear in RD Web Access when configured to use the RD Broker

Whilst building a new RDS server farm I ran across a problem which had me stumped for a few hours.  When configuring RD Web Access you need to specify a source for the RemoteApps, either an RD Broker or a bunch of Session Hosts as per the following screenshot.

When I selected "An RD Connection Broker" and specified the name of the broker server, I did not get any RemoteApps appearing in my "RemoteApps Programs" tab.  However when I specified the name of a Remote Desktop Session Host, the applications on the session host appeared as selected.

After much troubleshooting the problem was identified.  On each RD Session host server there is a local group called "TS Web Access Computers" which documentation on TechNet says you must nest the computer accounts of any RD Session Hosts for which you want applications published.  However if you wish to publish applications through an RD Connection Broker, you must nest the RD Connection Broker computer account inside this group instead.  I found this a little unclear in the TechNet documentation.  After fixing up the group nesting the problem was resolved.

How to Add a Computer Account to a Restricted Group in Group Policy

There may be a time where you need to add a computer account to a number of local groups using Group Policy restricted groups.  Computer accounts however do not appear in the list of Object Types within Group Policy.

It is however possible, simply add the computer account without clicking Browse in this format:

DOMAIN\ComputerAccount$

As long as you add the dollar sign $ at the end of the computer account name, group policy will process it.

Open File - Security Warning with AppData Folder Redirection

In the process of setting up a new Windows Server 2008 R2 RDS server farm I came acros the following problem.  Whenever opening ANY application on my RD Session Hosts, I received the following "Open File - Security Warning".

After a bit of investigation I noticed that this error was occurring because I had a folder redirection policy in place for user Application Data.

To resolve the problem I noticed if I add the UNC path to where I'm redirecting the AppData to Internet Options, Local Intranet it resolves the problem.

This resolves the problem.  However I have multiple users I want to configure this setting for.  To configure this against multiple users using group policy, configure the following setting located under:

User Configuration --> Policies --> Windows Settings --> Internet Explorer Maintenance --> Security --> Security Zones and Content Ratings

Under Security Zones and Content Ratings, select Import the current security zones and privacy settings then click Modify Settings.

When the Internet Options dialog box opens, configure the Local intranet zone as above and save the settings.

Apply the group policy object to the users experiencing the problem.

Rename VMDK files in ESX

vSphere Client v4-v5 does not allow you to rename a VMDK file through datastore manager.  To rename a VMDK you must do this through management shell (SSH).

To enable the Shell through the GUI refer to the following screenshot:

Once in the shell, login through an SSH client such as Putty.

Navigate to the location in your VMware datastore in which you wish to rename the VMDK using the following command:
cd "/vmfs/volumes/Datastore Name/Directory Name/"

Use the following command to rename the virtual machine:
vmkfstools -E examplevm.vmdk examplevm-renamed.vmdk

Why upgrade to Exchange 2013?

Your a company stakeholder, your currently running Exchange 2010, it sends and receives emails (lets hope).  Why should you spend the money and upgrade to Exchange 2013?

In this article we are going to look at some of the new features of Exchange 2013 which I believe will wet your appetite for implementing Exchange 2013.

Email Malware Protection

Back in 2009 I wrote a blog post on how to protect an Exchange 2007/2010 server from spam using the native spam filtering technology built into the product such as RBL providers, Intelligent message filter (IMF) and safe list aggregation.  This blog post can be found here:

http://clintboessen.blogspot.com.au/2009/10/exchange-2007-anti-spam-filtering.html

When configured correctly, it works pretty darn good!  I use native Exchange email protection for my personal Exchange server and with the RBL providers I have in place, I receive very little spam.

The problem is this solution cannot be deployed to customers as it was missing anti-virus technology and whilst I know what emails are malicious or not, there was nothing from stopping a receptionist from opening that FedEx.zip attachment for her package in the post which is running late.

In Exchange 2013 Microsoft have now incorporated the Microsoft Anti-Malware engine into Exchange.  Combined with Safelist Aggregation, RBL Providers and Microsoft IMF, the integrated Anti-Virus and Anti-Spam technology is great for any company on a tight budget.

Better Administrative Delegation for Large Organisations

Exchange 2013 provides better administrative delegation for large organisations through the use of RBAC.  When your help desk staff and specialist users login to to the new Exchange Administration Center (EAC), EAC only displays items to areas of interest the user has access to.  All other features of Exchange are not displayed to the user.

Whilst Exchange 2010 also had RBAC, delegating access to help desk to perform a simple tasks such creating and managing recipient mailboxes was painful.  With the old management tools in Exchange 2010, whilst users only had access to perform specific tasks, they were able to see the entire console.  When users attempted to perform a task which they do not have access to, they would receive a nasty error message.  This is no longer a problem moving forward with Exchange Administration Center (EAC).

eDiscovery Center

eDiscovery Center is a new tool which allows Administrators and compliance officers to preserve and discover data across your entire organisation.  No this is not the multi-mailbox search tool introduced in Exchange 2010, this tool allows you to identify, hold and analyze your organizations data from Exchange, Sharepoint and Lync all from a single console.  With eDiscovery Center the data remains in-place so there is no need for a seperate store.

For technical readers, to use the eDiscovery Center you need to be a member of the Discovery Management role group just like you did for Multi-Mailbox search in Exchange 2010.

For eDiscovery center to work between applications you must also be running Lync 2013 and Sharepoint 2013.

New Site Mailboxes

A couple of my larger customers have done survey's to end users asking them what their favorite or most productive line of business application is.  In each servery the answer has always come back with "Outlook".  Lets face it, most of us office workers live in Outlook, its an application which doesn't get closed!  Microsoft has taken this feedback on board and provided a new type of Mailbox called a site mailbox.

A site mailbox allows users to access documents from a Sharepoint site through the Outlook client meaning the user no longer has to go to the Sharepoint web interface.  Not only can they open documents through Outlook, they can also preview documents through the Outlook interface.

Luckily the Exchange team came to the rescue here, Sharepoint was never that great at sharing now was it?  Sorry to any Sharepoint administrators reading this - but you know its true :)

To utilise Site Mailboxes, the following software must be utilised together::

• Outlook 2013
• Exchange 2013
• Sharepoint 2013

To answer your question about OWA support, Yes, Site Mailboxes are available through Outlook Web App.

Data Loss Prevention (DLP) Capabilities

Data Loss Prevention capabilities is a technology Exchange server has required for some time to meet various industry compliance requirements such as PCI DSS compliance for handling credit card information. The new Exchange DLP features identify, monitor, and protect sensitive data such as credit card details through deep content analysis.  Exchange offers built-in DLP policies based on regulatory standards such as PII and PCI, and is extensible to support other policies important to your business.

New Policy Tips (the new version of Mail-Tips) supported as of Outlook 2013 inform users about policy violations as content is being created and about how information should be handled according to organizational standards.

The following screenshot shows policy tips prompting an Outlook 2013 that the attachment containing fake credit card numbers has indeed credit card numbers.

The New Windows 8 Experience

Your users will love you for it.  The sexy Windows 8 style experience is now available to both Outlook and OWA.  OWA user experience scales beautifully for any form factor and size – PC or slate or phone – and has a modern user experience voice with great support for touch and motion. OWA now offers three different UI layouts optimized for desktop, slate, and phone browsers.

No need for OWA Mini (introduced in Exchange 2010 SP2), the new OWA looks great on tiny screens such as mobile phones.

The following screenshot shows OWA 2013 on PC, Tablet and Mobile Phone.

While we are talking about OWA, I would also like to point out that in Outlook Web Access 2013 you no longer needs a constant Internet connection to operate.  Provided you have Internet access to load the Outlook Web App page, you can work in Outlook Web App in offline mode with no network connectivity.  Your emails will automatically synchronise the next time the internet connectivity is restored.  This provides users a great OWA experience from remote locations or connections with intermittently connected network.

Public Folders

Public Folders, yes they are still around however now they are new and improved.  Public Folders are no longer stored in a separate public folder database like they were in previous versions of Exchange.  Public Folders have been moved to whats known as a Public Folder mailbox.  This means they share the same storage, indexing capabilities, and high availability technologies utilised such as Database Availability Groups (DAG).

Because public folders are now stored in DAGs as a new type of mailbox, "Public Folder mailboxes", they are no longer multi-master.  Lets face it, public folders in multi-master were always an epic disaster due to the number of replication conflicts which were generated so loosing this will not be a big deal moving forward.  There are better technologies available for dealing with replication conflicts such as Microsoft Distributed File System.

The nightmare of maintaining public folders is also now gone, no more SMTP replication of data between mailbox servers.  As Public Folder databases sit within database availability groups, they replicate using standard transaction log shipping.  Wonderful.

I hope this post has been useful.  For more information on Exchange 2013 please see the Exchange 2013 section of my blog and also make sure to follow the Exchange Team Blog!

A first look into Exchange 2013

In this post I will be taking an initial look into Exchange 2013, the next release of Microsoft Exchange scheduled for release later this year.  This post contains only information which is publicly available.  Exchange 2013 is the biggest architectural change in Exchange server since Exchange 2007.

Exchange 2013 is a new generation of Exchange, let me explain what I mean by the new generation.

Exchange 5.5 and below is generation 1 of the product, the initial build of Exchange before Active Directory came into play.

Exchange 2000-2003 is generation 2 of the product, in which significant changes to the product were made.  From Exchange 2000 upwards, Exchange began storing majority of its configuration within Active Directory.

Exchange 2007-2010 is generation 3 of the product where we saw a huge architectural changes such as the concept of 5 Exchange server roles.

Exchange 2013, also known as Exchange build 15 is generation 4 of the product.  In Exchange 2013 we have now consolidated majority of the roles back to a single role much like it was in Exchange 2013.

When Exchange 2013 is released as RTM there will be a total of 2 roles.  These roles will consist of:

• The mailbox server role (formally known as a back-end server in Exchange 2003)
•  The client access server role (formally known as a front-end server in Exchange 2003)

If you have a long working history with Exchange server, think of Exchange 2013 architecture as it was in Exchange 2000/2003.  Client access servers proxy the connections, the mailbox servers do all the work.

Exchange 2013 Client Access Server

The Exchange 2013 client access server proxies connections to Exchange 2013 mailbox servers such as Microsoft Office Outlook, Outlook Web App, Mobile Devices, POP, and SMTP.  Client access servers can still be organised into CAS Arrays like they were in Exchange 2010.  Client Access servers perform authentication, redirection, and proxy services; it doesn't perform any data rendering utilizing internet information services (IIS).  All Exchange Web Service virtual directories exist in the Exchange 2013 mailbox servers just like they did in Exchange 2003.  The client access server merely proxies the connection to the correct mailbox server which is now responsible for processing the request.

Because all data rendering for web services is now performed on the Exchange 2013 mailbox servers, all connections to the Client Access server are stateless which means that there is no need to maintain affinity between a client and an individual Client Access server for subsequent connections because all data processing and transformation occurs on the Mailbox server.  This architecture change means simple "stupid" load balances can be used with no affinity or affiliation required.  In majority of cases Microsoft Network Load Balancing (NLB) with all its weaknesses is more then enough to load balance Exchange 2013 client access.

One big change in Exchange 2013 is all client access connectivity to Exchange 2013 must come in through HTTPS.  The MAPI protocol is now just a back end protocol for the mailbox servers.  Outlook must connect through RPC over HTTP(s) both internally and externally.

Whenever you deploy an Exchange 2013 client access server in an Active Directory site, you must also deploy an Exchange 2013 mailbox server in the same Active Directory site.

Exchange 2013 Client Access Architecture

When you deploy an Exchange 2013 client access server array, there are two components

• Client Access service
• Front End Transport service

The Client Access service provides the following services:

• Provides a unified namespace, authentication, and network security.
• Handles all client requests for Exchange.
• Routes requests to the correct Mailbox server.
• Proxies or redirects client requests for legacy servers, such as Exchange 2007 and Exchange 2010 Client Access.
• Enables the use of layer 4 (TCP affinity) routing... i.e. stupid load balances with no affinity.

The Front End Transport service provides the following services:

• Protocol level filtering   Performs connection, recipient, sender, and protocol filtering
• Network protection   Centralized, load-balanced egress and ingress point for the organization.
• Mailbox locator   Avoids unnecessary hops by determining the best Mailbox server to deliver the message to.
• Load-balances client and application SMTP requests.

The Front End Transport service can't inspect message content, but it has complete access to the SMTP protocol conversation, so it can filter messages based on connections, domains, senders, and recipients.  There is no queue on the Front End Transport service, mail is simply proxied directly to a mailbox server.  Because the Front End Transport service is aware of TCP connections you can configure some spam filtering however such as RBL providers such as Spamhaus.  For content filtering such as Exchange intelligent message filter (IMF), you guessed it, this needs to be performed on the  mailbox servers unless you have a smart host in play.

Exchange 2013 Mailbox Server

Just like in Exchange 2003, the Exchange 2013 Mailbox Server is once again the work horse of Microsoft Exchange.  The Exchange 2013 Mailbox Server has taken on tasks from many of the roles such as client access services, hub transport services and unified messaging services.  For example:

• All Outlook Web App, Active Sync and Outlook Anywhere (RPC over HTTP) sessions are processed on the Exchange 2013 mailbox servers
• The message queue and mail routing is performed on the mailbox servers (which the exception of the mailbox locator service on the client access which provides the ability to always deliver inbound mail to the correct mailbox server in the same AD site)
• Provides Unified Messaging services
• And of course it acts as a mailbox server providing companies enhanced Database Availability Groups (DAGs) which are improved over Exchange 2010.

The below diagram shows a high level overview of the Exchange 2013 architecture inside a single Active Directory site.

Why the big change?

Now why did Microsoft make such significant changes to the Architecture in Exchange 2013?  When Exchange 2007 released the concept of a multi-role servers, processing power was significantly less then what it is today.  Large scale deployments of Exchange 2003 which extended into the hundreds of thousands of users faced significant resource limitations due to hardware back in the day.  Microsoft needed to address this to allow Exchange to extend into larger scale deployments and as a result separate the server roles.

Due to a lot of smart people doing a lot of smart things over the years, today's servers have so much grunt we are virtualising to try and make use of it all.  This architecture of multi-role servers no longer makes sense!  In fact for large scale deployments of Exchange, as of Ex2010 SP1, Microsoft started recommending building all Exchange 2010 servers as multi-role servers and simply adding an additional server when required as a simple unit of scaling out.  The recommendations for multi-role Exchange servers can be found here:

http://technet.microsoft.com/en-us/library/dd298121.aspx

Now the problem here is the Exchange 2010 roles have been designed to run on separate servers and when all installed on the same server they still follow the same processes to communicate with one another through a TCP network call on localhost.  This creates inefficiencies as separate roles are all operating on the same server when the roles could be more incorporated to work more as one to provide better performance.  In fact this is one of the selling points behind Exchange 2013 from Microsoft:

"been re-written in managed code to improve performance in additional IO reduction and reliability."

Requirements

First of all what operating systems are supported to install Exchange Server 2013?  Easy one:

• Windows Server 2008 R2 Standard, Enterprise and Datacenter Editions or higher.  Make sure it is R2 as 2008 is not supported.
• Windows Server 2012 

What about migrating to Exchange 2013?  Migrating to Exchange 2013 is only supported from:

• Exchange 2007
• Exchange 2010

Despite all the noise I made whilst in Seattle earlier this year, the Exchange product team will not be supporting Exchange 2003 co-existence even though there are still many customers running Exchange 2003. I guess this just means the uptake to Exchange 2013 will not be as fast as those customers will need to perform a step migration through either Exchange 2007 or Exchange 2010.

Whilst Exchange 2013 now has greater support for IPv6 such as Unified Messaging now supporting IPv6, a pure IPv6 environment isn't supported.  IPv6 is only supported when IPv4 is also used.

Active Directory requirements are that of 2003 Forest Functional Level (FFL) and 2003 Domain Functional Level (DFL) or higher.  Schema master must run on Server 2003 SP2 or higher.

At this stage Exchange 2013 only supports the following clients:

• Outlook 2013 Preview
• Outlook 2010 SP1 with April 2012 Cumulative Update 
• Outlook 2007 SP3 with July 2012 Cumulative Update
• Entourage 2008 for Mac, Web Services Edition
• Outlook for Mac 2011

Multi-Role Servers

Can you install the Exchange 2013 Client Access Role and the Exchange 2013 Mailbox Role on the same server?

The answer is Yes.

Edge Transport Role

Currently there is no Edge Transport role for Exchange 2013.  Microsoft are advising customers to use Exchange 2010 SP2 Edge Transport with Exchange 2013 for now.  Due to a tight product release time frame the Exchange product team have not had time to develop the Exchange 2013 edge transport role however this role will be released in the future through a service pack.

A New Management Interface

The popular Exchange Management Console (EMC) which was used by for managing Exchange 2007/2010 has been removed from Exchange 2013.  Administrators are provided two methods for maintaining an Exchange 2013 environment:

• Exchange Management Shell (EMS) - also available in Exchange 2007/2010
• Exchange Administration Center (EAC) - new in Exchange 2013.

Exchange Administration Center is a web based administration console for Exchange.  Personally I don't agree with this decision as Microsoft has produced Microsoft Management Console (MMC) to be the standard for managing a windows network - this diverts away from the standard.

The main reason why Microsoft moved towards a web based interface for managing Exchange is due to Role Based Access Control (RBAC).  RBAC provides a granular method for delegating control to administrators.  With Exchange Management Console in Exchange 2010, when an administrator delegates a service desk operator to perform basic tasks such as create and manage recipient mailboxes, the service operator is able to perform his duty however is able to view all other features and functionality normally presented in EMC.  With EAC in Exchange 2013, the web console hides all administrative features and functionality except for the areas the user has been delegated access to.  With MMC hiding features is a difficult task which I believe is the prime reason Exchange management has been moved to a web interface.

There are also other benefits to having a web based management tools which EAC provides.  Administrators can now maintain Exchange environments from any PC with a web browser.  Yes - EAC does provide multi-browser support including all the major web browsers such as Chrome, Firefox, Safari and of course Internet Explorer.

Operation failed. Error code: 0x8007200a

We had a problem with a group policy object which existed in SYSVOL however did not display in Group Policy Management Console.  All group policy objects are located in the Active Directory schema domain partition under:

Domain --> System --> Group policies

You can view these policies using ADSI Edit by connecting to the default domain partition.  The policy that was showing up in SYSVOL was also displaying in ADSIEdit however we could not view any attributes on the object, or the objects class.  When trying to delete the object we got the following error.

Operation failed.  Error code: 0x8007200a
The specified directory service attribute or value does not exist.

This problem occurs when you do not have permissions to view the attributes of the object.  Check that you have ALLOW permissions to read the object or that there are no DENY permissions.  In our case someone had set Enterprise Admin to DENY read, hence the issue.

Windows Desktop Search 4 lagging Outlook

When utilising Microsoft Outlook in Cached Exchange Mode, Windows Desktop Search 4 is used to index the content in the Outlook OST to allow users to perform fast searches for emails and content within Outlook.  When Windows Deaktop Search 4 goes to first index email within a users inbox, this creates large amounts of local disk activity on the users workstation which causes performance issues especially if the user does not have a Solid State Disk (SSD).

This can be resolved by throttling the amount of items Windows Desktop Search 4 can index per minute.  Use group policy to implement Windows Desktop Search throttling by modifying the following group policy setting:

Computer Configuration\Administative Templates\Windows Components\Search\Enable throttling for online mail indexing

Here we have it limited to only index 60 mail items per minute.  This resolved Windows Desktop Search performance issues at my clients site.

MapiExceptionNetworkError: Unable to make connection to the server. (hr=0x80004005, ec=2423)

When performing cross-forest mailbox moves you will experience an error if your Exchange 2010 server cannot resolve BOTH the FQDN and NetBIOS name of your remote Exchange server and Global Catalog.  This error can occur when performing a cross-forest mailbox move from Exchange 2010, Exchange 2007 (SP2 and above) and Exchange 2003 SP2.  Provided you have already run the Prepare-MoveRequest.ps1 script, when attempting the mailbox move the following error may be experienced:

MapiExceptionNetworkError: Unable to make connection to the server. (hr=0x80004005, ec=2423)
Diagnostic context:
    ......
    Lid: 16280   dwParam: 0x6BA      Msg: EEInfo: ComputerName: n/a
    Lid: 8600    dwParam: 0x6BA      Msg: EEInfo: ProcessID: 2888
    Lid: 12696   dwParam: 0x6BA      Msg: EEInfo: Generation Time: 2012-07-21 10:56:50:629
    Lid: 10648   dwParam: 0x6BA      Msg: EEInfo: Generating component: 18
    Lid: 14744   dwParam: 0x6BA      Msg: EEInfo: Status: 11001
    Lid: 9624    dwParam: 0x6BA      Msg: EEInfo: Detection location: 320
    Lid: 13720   dwParam: 0x6BA      Msg: EEInfo: Flags: 0
    Lid: 11672   dwParam: 0x6BA      Msg: EEInfo: NumberOfParameters: 1
    Lid: 8856    dwParam: 0x6BA      Msg: EEInfo: prm[0]: Unicode string: kbombserver.kbomb.local
    Lid: 45169   StoreEc: 0x977
    Lid: 52465   StoreEc: 0x977
    Lid: 60065
    Lid: 33777   StoreEc: 0x977
    Lid: 59805
    Lid: 52209   StoreEc: 0x977
    Lid: 56583
    Lid: 52487   StoreEc: 0x977
    Lid: 19778
    Lid: 27970   StoreEc: 0x977
    Lid: 17730
    Lid: 25922   StoreEc: 0x977
    + CategoryInfo          : NotSpecified: (0:Int32) [New-MoveRequest], RemoteTransientException
    + FullyQualifiedErrorId : 724FCAC2,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest

In this environment I could resolve my Exchange 2007 server from my Exchange 2010 server through NetBIOS name however not through FQDN.  Remember, you need to be able to resolve both.

There are a few ways you can make the FQDN resolve, these include DNS, Host File or a DNS Suffix on the server.  I simply added a zone file in DNS for my Exchange 2010 forest to allow me to complete the cross-forest mailbox moves.

I can now resolve both NetBIOS and FQDN of my Exchange 2007 server.

After being able to resolve both the NetBIOS and FQDN, the mailbox move completes successfully.

Unknown StartTrace error (183)

If the Exchange User Monitor (ExMon) crashes, when relaunching the ExMon application you will get the following error:

Unknown StartTrace error (183)

This error occurs because there is still an active Event Trace open.  To resolve this problem you need to kill the active Event Trace.  In Windows Server 2000/2003 the Event Trace can be killed using a tool called Tracelog.exe which can be downloaded from the following URL:

http://www.microsoft.com/en-au/download/details.aspx?id=1370

In Windows Server 2008 the Event Trace can be killed using a tool called Logman.exe

To view all Data Collector Sets currently running on a Windows 2008 server with Logman run the following command:

logman query -ets

To kill the event trace use the following command:

Logman stop "Exchange Event Trace" -ets

After stopping the Event Trace, ExMon will now load correctly.