Connect Office 365 using Windows PowerShell from your local computer

Connect Office 365 using Windows PowerShell from your local computer

1.             Click Start, point to All ProgramsàAccessoriesàWindows PowerShellàWindows PowerShell.

             (assumption you already run the Set-ExecutionPolicy RemoteSigned command)

2.             Run the following command:

$LiveCred = Get-Credential

 

 

3.             In the Windows PowerShell Credential Request window, type the credentials of an account in your Office 365 organization. Then, click OK.

4.             Run the following command:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection

 

                  

5.             Run the following command:

Import-PSSession $Session

 

 

 

 

 

6.             To disconnect Windows PowerShell from the Office 365 service

When you're finished disconnect Windows PowerShell by running the below command:

                Remove-PSSession $Session

 

 

Note:-If you close the Windows PowerShell window without disconnecting from the Office 365 session, your connection will remain open for 15 minutes. Your account can have only three concurrent connections to the Office 365 session at one time.

Check Office 365 Service Upgrade Status using PowerShell

Check Office 365 Service Upgrade Status using PowerShell

 Microsoft will send you are scheduled for upgrade by our automated scheduling system, Microsoft will provide a notification in your Office 365 admin portal and send the Office 365 global administrator a notification email. The first notification provides you approximately four weeks advanced notice before your upgrade will begin, so you have time to take pre-upgrade steps, if needed. As the upgrade date approaches, Microsoft will send an email with the exact upgrade date (Only one time you can postpone the upgrade process).

You can verify your organization version from the below PowerShell command

Steps

1. Install  Windows Azure Active Directory Module for Windows PowerShell
2. Launch Windows Azure Active Directory Module for Windows PowerShell
3. Execute the following commands:
   
   Import-Module MSOnline
   Connect-MsolService
    (Get-MsolCompanyInformation).CompanyTags

Find the below screenshot for reference.

  4. Type your Global or Company Administrator credentials

 

 

5. Launch Windows PowerShell and connect to Office 365 and run the following commands to gather more information of the Wave 15 upgrade.

 

 Get-OrganizationConfig | Format-List AdminDisplayVersion

 

Get-OrganizationConfig | fl Name, Admindisplayversion, IsUpgradingOrganization

 

 

 

  6. Close the Office 365 session once you complete the activity.

 

 

 

Note:-If you close the Windows PowerShell window without disconnecting from the Office 365 session, your connection will remain open for 15 minutes. Your account can have only three concurrent connections to the Office 365 session at one time.

 

 

 

 

 

 

Transport architecture from the perspective of the Management Shell

This section briefly reviews the core transport architecture from the perspective of the Management Shell

Get-Queue

Set-Queue
Suspend-Queue
Resume-Queue
Retry-Queue
Get-TransportPipeline
Get-TransportServer
Set-TransportServer
Get-TransportConfig
Set-TransportConfig
Get-NetworkConnectionInfo

To view the Hub Transport pipeline, use the Get-TransportPipeline cmdlet as shown in

The TransportPipeline cmdlet also exposes two transport agents installed by default on the Hub Trans port server: the Journaling Agent and the Transport Rule Agent

Messages can enter the transport pipeline through any of four methods:
* Through an SMTP Receive Connector communicating on port 25.

* Through message files dropped into the Pickup or Replay directories.

* Through placement of messages in the Submission queue by the store driver.

* Through message submission via an agent.

How to get delaynotifiaction and messageExpiration timeout

Using the Set-TransportServer cmdlet you can modify these settings.

Test-MapiConnectivity

This is just FYI on a cmdlet which I use daily – Test-MapiConnectivity!

Use Test-MapiConnectivity to troubleshoot connectivity problems. Remember as the name implies, it will only test MAPI connectivity.

Use this to test connectivity between your users and your servers.

Use it in the following format:

Mailboxes: Get-Mailbox <Mailbox Name> | Test-MapiConnectivity

Mailbox databases: Get-MailboxDatabase <Database Name> | Test-MapiConnectivity

Servers: Get-MailboxServer <Server Name> | Test-MapiConnectivity

A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working

You configure a failover cluster on some computers that are running Windows Server 2008 R2 and communication failure occurs in the cluster.

Below is the Link from Microsoft Link which resolve the Issue

http://support.microsoft.com/?kbid=2550886

How to remove a mail of mailbox database from server end

User R2 sends an email to a set of people with the subject line “I Love you”. Now, Stallone being the IT manager wants you to delete that email from the server side.

All you gotta do is to run this cmdlet:

Get-Mailbox -Server EXCH | Export-Mailbox -TargetMailbox TempMailbox -TargetFolder ” To Delete” -SenderKeywords R2@E2Esolultions.com -SubjectKeywords ” I Love You ” –StartDate “07/03/13″ –EndDate “07/04/13″ -ExcludeFolders “\Calendar”, “\Contacts”, “\Deleted Items” –DeleteContent –MaxThreads 10

Terms

* Server name is EXCH

* Data will be extracted from user mailboxes to the folder “To Delete” in a mailbox called TempMailbox

* Start date and End Date switch let you choose a date range

* Set the ExcludeFolders switch if you don’t want to search specific folders

* DeleteContent is the switch which deletes the email

* MaxThreads is to specify 10 mailboxes will be processed at a time

Now remember that Export-Mailbox first copies content to the destination mailbox before performing the search and the target mailbox can get quite large and create heavy IO. This is different from creating a transport rule to filter incoming messages.

Users can still use the “Recall” option in outlook.

Exchange 2013 Server Role Architecture

Exchange Server 2010 incoming email with Chinese characters

Working with an outside company that sends automated emails
to us, these emails are html formatted, but when they arrive
the html tags are missing almost every < symbol and added
were chinese characters throughout. It looked something like
this : "ℼDOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN"> 䠼TML>䠼EAD> 䴼ETA http-equiv=Content-Type
content="text/html; charset=unicode"> 㰊META content="MSHTML
5.50.4807.2300" name=GENERATOR>⼼HEAD> 㰊BODY㰾FONT size=2> 吼
ABLE border=1> 吼R> 吼D>䘼ONT size=2>" 

Took a while to find the issue and resolution. Turns out
that the MIME type in the header didn't match either the
encoding type of the email, or our legal notice that gets
added was in a different encoding type, which made Exchange
mess up all of the tags. It could also be because Outlook
uses Word as its HTML viewer instead of IE.

The solution is to add a line to the
edgetransport.exe.config file,
key="DisableDetectEncodingFromMetaTag" value="true" />

This forces Exchange to figure out the encoding on its own
and not trust the MetTag

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.

Exchange 2013 CU2 Coming Summer with Restored 100-Database Support

Microsoft announced that it will release Cumulative Update 2 (CU2) for Exchange Server 2013 sometime this summer.

For the Enterprise edition, the update will increase the maximum number of supported databases per server from the current 50 to 100, according to a post on the Exchange blog by Ross Smith IV, principal program manager for Microsoft's Exchange Customer Experience team.

In developing Exchange 2013, Microsoft initially lowered the limit for supported databases from 100 to 50 to improve performance. The company is restoring the original 100-database limit with CU2 in response to user complaints, Smith said.

"Since the release of Exchange 2013, we've received an inordinate amount of feedback regarding the reduction in supported databases per-server. The driving response has been 'we currently deploy more than 50 databases per-server in Exchange 2010; with this change, this means we will need to deploy more servers, which increases our capital expenditures significantly,'" he wrote. "Rest assured, that is not the message we want with Exchange 2013. It is true that Exchange 2013 utilizes more CPU and memory than its predecessors -- this is due to the architecture changes we've made, as well as the changes we've made to reduce disk IO, so that you can deploy more mailboxes per disk. But we do not want to see architectures artificially limited by the supported databases per-server constraint.

Smith explained the reasoning behind cutting the number of supported databases in the first place. He said that Microsoft initially thought that there was a "lack of real world usage" beyond 50 databases per server, but that customers said otherwise.

The new server supports the use of commodity hardware and its new architecture made the product more CPU- and memory-reliant than Exchange 2010, Smith explained. Microsoft replaced the old content indexing service with Search Foundation and rewrote the store.exe process. Those architectural changes and a few more were somehow associated with the 50-database limitation, perhaps, per Smith's explanation, although it's not exactly clear why.

CU2 will become available "later this summer," Smith said. Microsoft released CU1 of Exchange 2013 in April. Earlier this year, Microsoft announced it would adopt a quarterly release schedule for Exchange 2013 cumulative updates, which are different from update rollups (RUs). Cumulative updates, as their name suggests, contain all past updates and hotfixes, including past update rollups. On the other hand, update rollups are sequential, meaning an RU2 of one product will not contain security fixes from RU1.

Managing Active Directory Site limits

Connectors are really good objects to control limits for external recipients, however, when an organization wants to limit internal users, there is a better way to do that. It is through Active Directory Site links.

Let’s say that we have 3 main sites (Porto Alegre, Buenos Aires and Montevideo) say that the link to Argentina is really bad and messages with more than 1MB will stop the ERP because we don’t have QoS in place In this scenario we could use limits at Site Level and the following cmdlets will help us out:

Get-ADSite: It lists all Active Directory sites

Get-ADSiteLink: this cmdlet lists all IP Inter-Site Transport entries

Set-ADSiteLink: this cmdlet sets the MaxMessageSize attribute

Understanding Client Throttling Policies

Exchange Server 2010 uses client throttling policies to manage the performance of your Exchange organization. To do this, Exchange tracks the resources that each user consumes, and enforces connection bandwidth limits, as necessary

Exchange Server 2010 SP1, all client throttling policies are turned on by default. If you are experiencing problems that may be caused by these policies, you can turn off client throttling. To turn off client throttling, you can set all policy parameters to $Null

Exchange 2007 introduced a feature called RPC Client Throttling to allow administrators to manage end-user performance by preventing client applications, such as Outlook for example, from sending too many Remote Procedure Call [RPC] requests per second to Exchange, causing the server to suffer in terms of performance. When Exchange determines that a client is having a negative effect on the server, it will send a "back-off" request to the client telling it to delay sending any additional requests for a specified time (maximum of 2000 milliseconds) in order to reduce the performance effect on the server.

In Exchange 2010, Client Throttling has been much improved, monitoring and controlling much more than just RPC requests. Its purpose is still to ensure that users are not intentionally or unintentionally straining Exchange and that users share resources proportionally.

There is also Message Throttling in Exchange that restricts the number of messages and the number of connections that can be processed by an Exchange Transport server. In this article we will be talking only about Client Throttling.

What is Monitored?

what does Exchange 2010 now monitor that Exchange 2007 didn’t? As I mentioned before, with Exchange 2010 it's not just RPC requests that are monitored, but 9 different components:

* Anonymous access

* Cross-Premises Access (CPA)

* Exchange ActiveSync (EAS)

* Exchange Web Services (EWS)

* IMAP

* POP

* Outlook Web App (OWA)

* RPC Client Access (RCA)

* PowerShell

Below command shows a Default Throttling Policy created in Exchange 2010 SP1

     Get-ThrottlingPolicy      

Throttling Policies are simply AD objects saved under:

CN=Global Settings, CN=Exchange Org, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=Domain, DC=COM

POP3 and IMAP4

By default, POP3 and IMAP4 are disabled in Microsoft Exchange Server 2010. To support clients that still rely on these protocols, you must first start the POP3 and IMAP4 services on the Exchange 2010 Client Access server. You must also configure SMTP for your POP3 and IMAP4 clients to send e-mail

Differences Between POP3 and IMAP4

POP3 is a frequently used e-mail Internet protocol. By default, when POP3 e-mail applications download e-mail messages to a client computer, the downloaded messages are removed from the server. When a copy of your user's e-mail isn't kept on the e-mail server, the user can't access the same e-mail messages from multiple computers. However, some POP3 e-mail applications can be configured to keep copies of the messages on the server so that the same e-mail messages can be accessed from another computer. POP3 client applications can only be used to download messages from the e-mail server to a single folder (usually the Inbox) on the client computer. The POP3 protocol can't synchronize multiple folders on the e-mail server with multiple folders on the client computer. POP3 also doesn't support public folder access

E-mail client applications that use IMAP4 are more flexible and generally offer more features than e-mail client applications that use POP3. By default, when IMAP4 e-mail applications download e-mail messages to a client computer, a copy of downloaded messages remains on the e-mail server. Because a copy of the user’s e-mail message is kept on the e-mail server, the user can access the same e-mail message from multiple computers. With IMAP4 e-mail, the user can access and create multiple e-mail folders on the e-mail server. Users can then access any of their messages on the server from computers in multiple locations

Outlook Anywhere

Outlook Anywhere feature, formerly known as RPC over HTTP, lets clients that use Microsoft Office Outlook 2010, Outlook 2007, or Outlook 2003 connect to their Exchange servers from outside the corporate network or over the Internet using the RPC over HTTP Windows networking component

Outlook Anywhere and Exchange 2010 Windows RPC over HTTP Proxy component, which Outlook Anywhere clients use to connect, wraps remote procedure calls (RPCs) with an HTTP layer. This allows traffic to traverse network firewalls without requiring RPC ports to be opened. In Exchange 2010, as in Exchange 2007, it's easy to deploy and manage this feature. To deploy Outlook Anywhere in your Exchange 2010 messaging environment, you need to enable Outlook Anywhere on at least one Client Access server

Note: - Outlook Anywhere should be enabled only on Client Access servers that are exposed to the Internet. Do not enable Outlook Anywhere on internal Client Access servers

Coexistence For mailboxes on Exchange 2010 Mailbox servers, clients must connect through Exchange 2010 Client Access servers. Outlook Anywhere can be used in environments where Microsoft Exchange Server 2007 and Exchange Server 2003 servers are still being used. If you have users with mailboxes on Exchange 2003 servers, and these users are using Outlook 2007 or Outlook 2003 to connect, you must configure these clients manually

Remote Device Wipe Works

Exchange ActiveSync policies, you can add a password requirement to your mobile phones.

In addition to resetting the mobile phone to factory default condition, a remote device wipe also deletes any data on any storage card that's inserted in the mobile phone.

Local device wipe & Remote device wipe

Local device wipe is the mechanism by which a mobile phone wipes itself without the request coming from the server. If your organization has implemented Exchange ActiveSync policies that specify a maximum number of password attempts and that maximum is exceeded, the mobile phone performs a local device wipe. The result of a local device wipe is the same as that of a remote device wipe. The device is returned to its factory default condition. When a mobile phone performs a local device wipe, no confirmation is sent to the Exchange server.