Log Parser Studio 2.0 is now available

Since the initial release of Log Parser Studio (LPS) there have been over 30,000 downloads and thousands of customers use the tool on a daily basis. In Exchange support many of our engineers use the tool to solve real world issues every day and in turn share with our customers, empowering them to solve the same issues themselves moving forward. LPS is still an active work in progress; based on both engineer and customer feedback many improvements have been made with multiple features added during the last year. Below is a short list of new features:

Download Link below:-

http://blogs.technet.com/b/exchange/archive/2013/06/17/log-parser-studio-2-2-is-now-available.aspx?goback=%2Egmr_1910476

Changes in Exchange Server 2013 public folder

Exchange supports moving your public folders from the following legacy versions of Exchange Server

* Exchange Server 2010 SP3

* Exchange Server 2007 SP3 RU10

You can’t migrate public folders directly from Exchange 2003. If you’re running Exchange 2003 in your organization, you must move all public folder databases and replicas to Exchange 2007 SP3 RU10 or later. No public folder replicas can remain on Exchange 2003

One of IT Admin's disappointments with Exchange 2010 is that PFs cannot be part of a Database Availability Group [DAG] and we still have to use the same replication method available for PFs to achieve resilience and high availability.

The good news is that with Exchange 2013 Preview, PFs do take advantage of the existing high availability and storage technologies of the mailbox store.PFs now being special mailboxes, there is no longer a Public Folder Database! The best part is that PF replication now uses the continuous replication model, and high availability for the PF mailboxes is achieved through a DAG, thus moving away from a Multi-Master Replication Model PFs had, to a Single-Master Replication Model of DAGs.

A Multi-Master Replication Model is one where you have two or more PF databases replicating between them. “Multi-Master” comes from the fact all PF databases are writable so you can have some users using one database, other users using the other database to access the same data, but their content is being constantly replicated between them, so all users have access to the same information. The problem is that this replication is done through SMTP messages sent between the servers holding the PF databases and is not very efficient, often causing conflicts when the same data is updated at the same time.

Because now PFs can be part of a DAG, we no longer have this multi-master replication model. Instead they replicate using the standard transaction log shipping method.

Changes in Exchange Server 2013

Exchange Server 2013 entirely changes how Public Folders operate

The main architectural changes that are introduced are:

*Public folders are now stored in a mailbox database

*Public folders now leverage a DAG for high-availability

Public Folder Mailboxes

Public folders are now also mailboxes, but their type is “Public Folder” (just like a Room Mailbox is a Mailbox with type “Room”). In a way, Public Folders still exist of two main elements mentioned above: the hierarchy and contents.

 * The hierarchy is represented by what is called the Master Hierarchy Public Folder Mailbox. This PF Mailbox contains a writable copy of your public folder hierarchy. There is only a single Master Hierarchy PF mailbox in the organization.

* Contents (in Public Folders) are now stored in one or more Public Folder mailboxes. These Public Folder mailboxes usually contain one or more Public Folders. Next to the contents, each PF Mailbox also contains a read-only copy of the hierarchy.

Note:-   because Public Folders are now stored in mailboxes, mailbox quota’s apply to them. For instance, this means that if a PF Mailbox would grow too large, you’d have to move Public Folders to another PF Mailbox (or increase the quota)

Exchange Server Updates & Coexistence with Exchange 2013

Exchange Team released Rollup 6 for Exchange Server 2010 Service Pack 2(KB2746164). This update raises Exchange 2010 version number to 14.2.342.3. And Rollup 10 for Exchange Server 2007 Service Pack 3 (KB2788321). This update raises Exchange 2007 version number to 8.3.298.3 

New Features with Exchange 2010 SP3:

Coexistence with Exchange 2013: Customers who want to introduce Exchange Server 2013      into their existing Exchange 2010 infrastructure will need the coexistence changes shipping in SP3.

Support for Windows Server 2012: With SP3, you can install and deploy Exchange Server 2010 on computers that are running Windows Server 2012.

Support for Internet Explorer 10: With SP3, you can use IE10 to connect to Exchange 2010.

Major issues resolved with Exchange 2010 SP3:

             2800346 Outlook freezes and high network load occurs when you apply retention policies to a mailbox in a mixed Exchange Server 2010 SP2 environment

             2800133 W3wp.exe process consumes excessive CPU and memory resources on an Exchange Client Access server after you apply Update Rollup 5 version 2 for Exchange Server 2010 SP2

Important information for organizations who install the update on computers that are not connected to the Internet

When you install this update rollup on a computer that is not connected to the Internet, you may experience long installation times. To resolve this issue, follow these steps:

* On the Tools menu in Windows Internet Explorer, click Internet Options, and then click the advanced tab.

* In the Security section, click to clear the Check for publisher’s certificate revocation check box, and then click OK.

Exchange 2013: New Features and Changes, Part 4

Administration

Exchange Administration Center
Exchange 2013 leverages the use of the web interface for administration of the majority of its components. The Exchange Management Console (EMC) is no longer available as a tool, but the majority of its functionality is found through the Exchange Control Panel virtual directory. This eliminates the need to install the heavy console on the computer you use to administer Exchange, providing more management flexibility. While some might be concerned with security, the web access is secured just like the EMC in previous versions, as it uses SSL as well to reach the Exchange components.

PowerShell
The Exchange Management Shell is still the advanced tool needed when it comes to more granular management, advanced features, and bulk tasks. There are hundreds of new PowerShell cmdlets in Exchange 2013 to reflect the various features that have been added to the product.

Testing and Upgrading Exchange Server 2013

Getting the latest software and new features to integrate in your current environment requires careful planning. While most organizations that are going to transition to Exchange 2013 have Exchange Server 2007 or 2010 running (2003 is not supported), the actual co-existence of 2013 with these earlier versions is a process that will only be feasible with the release of appropriate service packs and cumulative updates. The transition process will be similar to what was done when transitioning from earlier versions to Exchange Server 2010.

Schema upgrade: One of the first requirements, and a sensitive change, will be to update the schema to enable new objects and attributes from Exchange 2013 to be visible in AD. This step is not something new, as numerous previous versions use AD as the storage engine of Exchange settings.

Updates and service packs: Older versions of Exchange, as well as 2013 itself will need to run the latest software in order to fully merge versions and enable co-existence scenarios.

Exchange 2013 installation: This process involves the setup of Exchange 2013 within the same organization that is used by legacy versions of the product.

CAS configuration and co-existence: This step involves routing all client access to the 2013 CAS role by modifying existing DNS records to point to the newly installed server. The use of a new legacy A record allows redirection of users with older mailboxes to their legacy servers, while still providing a single point of access for all client scenarios. Tasks such as certificate changes to reflect legacy records must be done as well. Typically, Internet-facing sites are first affected by this change.

Mailbox configuration and co-existence: After determining and building the appropriate databases and storage settings on mailbox servers (including the creation of DAGs), moving mailboxes to the new server is normally a straight-forward process. Settings we should look after include transitioning the public folders, OAB generation servers, and few others, helping us gradually decommission the mailbox servers.

Mail flow configuration: Since the majority of mail flow settings are stored in AD, and SMTP is always used to exchange e-mails, the e-mail routing should be relatively simple; 2013 should be set to receive all incoming e-mail for the organization. As e-mail for legacy mailboxes enters the organization, the 2013 mailbox and CAS components will route the messages to appropriate legacy servers, where legacy mailboxes are stored. A similar technique applies to messages that leave a legacy mailbox, and recipients on 2013: AD will find which server is responsible for the 2013 mailbox, and legacy SMTP servers will transfer the message to appropriate 2013 e-mail routing servers.

With the mentioned steps, there will be a coexistence period, where multiple versions of Exchange will be present in the organization at the same time. This is a typical scenario, as it is often impossible to move a large number of mailboxes and eliminate legacy servers so quickly. However, this is not considered to be a problem in terms of taking advantage of Exchange 2013. As more mailboxes are moved to the new servers, more users will have the latest web interface, and administrators will benefit from simplified scalability scenarios, access methods, mail flow, and so on.

It is also absolutely feasible to install Exchange 2013 in a new forest/organization and test the product, while waiting for Microsoft to provide us with the appropriate service pack levels that will enable coexisting Exchange versions.

Given the number of tools and programs that often integrate with a messaging system, you may need to run multiple versions of Exchange Server for years. Decommissioning Exchange servers can be risky, given how complex an infrastructure can be. It can take quite a while to test and eliminate the risk of moving everything to the new version of Exchange.

Exchange 2013: New Features and Changes, Part 3

Mail Storage

Database Availability Groups (DAG) enhancements
Numerous features have been added in the database availability group components. The core functionality has not changed, as DAG is still the only way to make continuous replication work, but a few of them are reflected here:

It is now possible to run DAG on a standard edition of the Windows Server platform.
There have been improvements in site resiliency scenarios.
AutoReseed allows the restore process to happen more efficiently.
Active and passive databases can use the same storage.
The transport dumpster has been replaced by the Safety Net engine, which is similar, but simplifies the use of shadow queues, as well as lagged copies
There are numerous other changes, but the major one is the possibility of using database availability groups for public folder replication.

Database failure isolation
With the store itself redesigned, process isolation has been introduced. This functionality helps separate different processes for databases, diminishing the chances that a single database failure can affect other databases or the server itself. While this feature might take more processing, it is still considered an asset, helping in the stability and scalability of mailbox servers.

Redesigned public folders

In Exchange 2013, public folder databases no longer exist. Instead, you can create public folder mailboxes, create a hierarchy within them, and assign them to mailbox users. The issues with a traditional public folder database are no longer present. The multi-master replication is not used anymore, and these public folder mailboxes can now participate in database availability groups, and continuous replication mechanisms, as well as in all other scenarios that control and make traditional mailboxes available to users.

Shared mailbox
Previously configured delegated mailboxes can be converted to shared mailboxes, as they provide an easier way to access messages that are for helpdesk scenarios, generic inquiries, or other types of access that require a centralized approach in administering a mailbox. When a user is granted full control for the shared mailbox, it is possible to open that additional mailbox through OWA or link it to the Outlook profile.

Mailbox database limits
While the number has not changed for the standard version, the Exchange 2013 Enterprise limit is set to 50 databases per server. This decrease is mainly due to system performance. While 50 still seems to be a large number of databases, when you consider implanting DAG and creating multiple copies of your databases, this number can be reached fairly easily. Thus, new design considerations for storage will have to be planned.

Exchange 2013: New Features and Changes, Part 2

Mail Access
Outlook Web App (OWA) interface
Outlook Web App features numerous changes, but the most obvious is definitely the visual appearance, which now sports a sleeker and cleaner interface. Running OWA is almost the same end user experience as running Microsoft Outlook. Some organizations can consider leveraging the OWA interface as an alternative to the full messaging client.

OWA cache functionality
This key feature allows a user to to access OWA e-mail while the client is offline, since a local cache can be created in certain browsers (IE 10 and Chrome, for example). The cached content, stored in a web database format, includes e-mail and contacts, as well as calendar content. Recent content can be read, edited, saved as a draft, etc., basically allowing users to perform most common tasks while being offline and disconnected. This is a key feature of Exchange 2013 and will help users leverage OWA. It has the potential to become a real alternative to the full Outlook client.

The Remote Procedure Call (RPC) protocol
In legacy versions of the product, RPC was leveraged in quite a few scenarios. With RPC, a large numbers of ports had to be opened on firewalls, which allowed the Outlook client (internally connected) to reach the Client Access Servers. Also, a similar situation happened when communication between the mailbox and CAS or hub roles occurred.

In Exchange 2013, RPC is still used, but it is encapsulated within HTTPS in all instances. Communication between the previously mentioned components now all occurs through SSL, delivering more flexibility when dealing with mailbox proxying and client access.

There are other advantages with this kind of configuration, including less overhead because of the RPC service running on the CAS, the use of mailbox Globally Unique Identifiers (GUIDs), better site resiliency, and enhanced mailbox proxying.

Mailbox proxying
The optimal client connectivity scenario involves a user accessing a CAS found on the same site where the client mailbox resides. However, that does not always happens, as the client can access the wrong physical network, forcing redirection or proxying to occur.

In earlier versions of Exchange, we could use HTTPS proxying to help that remote client gain access to the mailbox through CAS to CAS communication.

For example, if a user connects to Site 1 and the target mailbox is on Site 2, Site 1 CAS proxies the connection to Site 2 CAS, where the mailbox server hosting the e-mail of this user is found. The Site 1 CAS is considered a relay, helping maintain the connection to the mailbox.

Depending on the connectivity method and topology design used, redirection or proxying had to be involved often, as mailbox and CAS servers that were in different sites could not communicate by design. The result was increased traffic between WAN links, and a greater utilization of the CAS servers, reducing the overall performance of the messaging infrastructure.

Exchange 2013 still uses proxying, but it is no longer necessary to involve CAS-to-CAS communication between sites, as a CAS and a mailbox in separate sites can now communicate directly. Based on the scenario above, this means we eliminate the additional connectivity of the relay CAS server in Site 1. This simpler configuration minimizes the need for the resource-intensive RPC protocol on WAN links.

Super proxy functionality
The CAS component in Exchange 2013 differs highly from the one we used with previous versions. In fact, the actual workload is not being performed on the CAS anymore; the data is rendered by the mailbox role and only displayed by the CAS. That not only means more load for the mailbox servers, but also a greater flexibility when it comes to designing the CAS infrastructure. Since these two servers share less information in common now, the CAS no longer needs to retain session-state and connectivity information. The CAS acts as a true proxy solution and will operate under different versions than the mailbox server runs on. It is presented now as a reverse-proxy solution.

However, it is still necessary to have both the mailbox and CAS on the same site, with appropriate other infrastructure servers (Active Directory [AD], DNS, global catalogs, etc.), just as in previous versions.

Managed Availability
This new feature provides a way to isolate and fix issues that can potentially affect the user experience. It can detect various problems and provide a way to fix them on the fly.

In short, it is composed of three parts:

A probe: This component acts as a monitor, taking samples and measurements of the end user mailbox access.
A monitor: The monitor analyzes the information provided by the probe to help find connectivity issues.
A responder: There are multiple responders designed to take action when the previous components discover a problem.

Unified Messaging (UM)
With these numerous changes at the infrastructure level, you might notice UM is not available as an option through the installation wizard. In fact, Unified Messaging has been split into two pieces, similar to the SMTP services, but has kept the same functionalities and is present on CAS as well as mailbox roles.

The UM call router service forwards calls to Mailbox Servers, performing the transport and proxying functions.

The UM service that runs on the mailbox server is responsible for the majority of the processing. This is where information such as auto attendants, gateways, dial plans, and other VoIP functionality is defined and used in UM scenarios.

Exchange 2013: New Features and Changes, Part 1

Mail Flow

SMTP Services

One of the first changes we notice during setup is that the hub transport role is no longer available for installation. In fact, it has been divided into two services that run on all client access server and mailbox roles.
A new service, the Front-End Transport Service, runs on the Client Access Server (CAS). This component provides basic spam scanning for incoming messages, quickly forwarding them to the appropriate mailbox servers. It also relays outgoing e-mail to the Internet or, preferably, to smart hosts. This service does not host a message queue.
The Front-End Transport Service is not a replacement for the Edge transport service (but can certainly use the 2010 version of the relay), and despite the fact it seems to be for the outside world, it is not supposed to reside in the perimeter of the network. When a message is exchanged between internal Mailbox servers, the CAS Front-End Transport Service is not used.
A mailbox server now fully integrates SMTP mail flow components.[g1]  In fact, that is where the core of e-mail flow happens. It contains different queues, and categorizers, pick-up directories, as well as other components that deliver e-mail to appropriate mailboxes. It is composed of two services:
·         Mailbox transport delivery: This component allows the internal e-mail routing engine to appropriately forward an incoming e-mail to the user’s mailbox.
·         Mail transport submission: This component routes the outgoing e-mail from a mailbox to the SMTP components to successfully deliver the e-mail to the next messaging server.

Malware and spam protection
Identifying viruses and threats is possible with Exchange Server 2013, as the malware protection component can be enabled for the organization. A message can be scanned for typical threats. This is a service that is now fully integrated into the architecture at no cost. However, it can also be paired with third-party products or Exchange Online Services.
Basic anti-spam filtering is also available in Exchange 2013 and is essentially the same engine as before. However, its configuration is no longer possible through the interface; it can only be done in PowerShell.

Data Loss Prevention
Data Loss Prevention (DLP) is part of the messaging compliance. It is now possible to look for specific patterns and keywords in messages to find confidential and sensitive information that could be outgoing. Combined with transport rules, DLP and appropriate policies it can help filter information and apply several policies that dictate how and what type of information can leave the organization.

Connectors
There is a change in the way connectors are pre-configured, following a typical installation. It affects the way back-end and front-end servers communicate; hence, the default connectors we see in the console are different from the ones seen in previous versions (primarily applicable to receive connectors).
The name changes can be somewhat confusing, so here is a summary of what is now available:
·         Default frontend: This connector allows inbound e-mail to be processed by the CAS role. It works on port 25. By default, now anonymous users can use this connector. This is one of the default legacy connectors as well.
·         Outbound proxy frontend: This connector running on the CAS is responsible for receiving e-mail from trusted mailbox servers in the organization. It uses port 717.
·         Client frontend: This connector allows clients to send e-mail directly to the CAS server through port 587. It exists in previous versions of Exchange Server.
·         Default: This connector installed on the mailbox role is used to exchange messages between mailbox servers. It uses port 25 if the mailbox and CAS are not on the same server. If the mailbox and CAS are on the same server, it uses port 2525.
·         Client proxy: This connector allows the mailbox server to receive e-mail from the CAS. It uses port 465.