Looks like Apple finally released an update to fit the exchange calendar bug

 

Update: iOS 6.1.2 resolves this problem

I have see a lot of reports lately about the Apple iOS 6.1 bug effecting organisations using Exchange 2010. The problem appears to occur when a user using a Apple device (iPad, iPhone, etc) with iOS 6.1 responds to or edits a single instance of a recurring calendar event, this causes excessive log growth and a significant increase in memory and CPU resource consumption in turn causing server performance to be affected. Both Microsoft and Apple have released support articles for this bug, but at the time of writing it has not been fixed.

If you do currently have a large iOS device fleet, I would suggest advising your users against upgrading their devices until this is resolved. If you are already experiencing resource problems on your Exchange servers, I strongly suggest using either a custom throttling policy for iOS 6.1 users or blocking iOS 6.1 users completely. For more information on these workarounds, see the following Microsoft support article.

A few moments ago the Microsoft Exchange Team announced the availability of Exchange 2010 SP3. I can’t remember any other service pack that has been as eagerly anticipated as this one, mostly because SP3 will allow coexistence with Exchange 2013 which was released late last year. Unfortunately, it appears that customers wanting to introduce Exchange Server 2013 into their existing Exchange 2010 environment will have to wait just a little longer for the release of Exchange 2013 CU1, or at least that is how I interpret the following release note on the Exchange Team Blog:

NOTE: Exchange 2010 SP3 allows Exchange 2010 servers to coexist with Exchange 2013 CU1, which is also scheduled to be released in Q1 2013. Customers can test and validate this update in a representative lab environment prior to rolling out in their production environments as an important coexistence preparatory step before introducing Exchange Server 2013 CU1.

This service pack also resolves numerous issues, a list of these can be found here.

To download Exchange 2010 SP3, click here.

In case you missed it, the evolution of hardware has caused an architectural change in Exchange 2013.. gone are the 5 Exchange server roles that we have all come to know and love since Exchange 2007. In Exchange 2013 things are a lot more simple with only two server roles, namely, the Client Access server role and the Mailbox server role. Don’t let the familiar names fool you though, there is nothing familiar about these roles. In Exchange Server 2013 there are two basic building blocks – the Client Access array and the Database Availability Group (DAG). Each provides a unit of high availability and fault tolerance that are decoupled from one another. Client Access servers make up the CAS array, while Mailbox servers comprise the DAG.

Ross Smith did a great job (obviously!) of introducing the new Exchange 2013 role architecture during the technical keynote at MEC 2012 last year.. if you have not already seen it, I highly recommend you watch it here. He also recently publish the following post of the Exchange team blog that covers the same topic.

As we are all aware, the next wave of Office 365 is currently in preview and will be available soon. One of the expected (and long awaited) new features is the ability to administer Lync Online via PowerShell, this is something that is lacking in the current release. I was recently working with a customer who are preparing for to transition several thousand users to Lync Online and this got me curious about remote PowerShell and Lync Online 2013. Since there is no documentation available yet for the upcoming release, I thought I would share my initial findings.

Before I go any further I should mention that at the time of writing this I am testing with a Office 365 Preview tenant and as with all things still in development, it is possible (likely even) the the final release will behave differently. I also want the mention that remote PowerShell does not work with Lync Online on an Office 365 Preview tenant (see details below) so I am sharing this information purely for those who might be interested in how it may or could work in future – I will of course update this post once the next wave of Office 365 has been released.

My discovery came after I installed the Lync 2013 administrative tools on my laptop, I was browsing around the modules folder when I noticed it had installed a module called “LyncOnlineConnector” which is not imported by default.

 

 

So as any curious geek would, I thought I would play around a little.. I imported the module and took a look at the cmdlets available.

 

 

Once imported, the “LyncOnlineConnector” module contains a “New-CsOnlineSession” cmdlet which according to the help file is used to set up a remote session to Lync Online.

 

 

If you attempt to run the cmdlet, you receive the following error: "Remote Windows PowerShell session creation is restricted by tenant Windows PowerShell policy". This leads me to believe that remote PowerShell is currently restricted on Office 365 Preview tenants.

Ever wondered what version of Exchange your tenant is provisioned on? Michael Van Horenbeeck has written quick post on how to determine this. I think this will be really handy in the near future so I wanted to share it.

You can check the version by issuing the following cmd via powershell:

Get-OrganizationConfig | ft AdminDisplayVersion,IsUpgradingOrganization

Michael has some great information in his post that can be found here so be sure to check it out.

Microsoft recently released KB2506146 and KB2506143 as optional updates depending on your which server version you are running (2008 SP2 or 2008 R2 SP1)

The update includes Windows Management Framework 3.0 and more specifically PowerShell 3.0 which is not supported on either Exchange 2007 or Exchange 2010. There have been reports of it causing issues with the installation of rollups resulting in an error code of “1603” appearing in the event log.

It is recommended that Windows Management Framework 3.0 should not be installed on servers running either Exchange 2007 or Exchange 2010. Uninstalling Windows Management Framework 3.0 reportedly fixes the issues.

I previously blogged about controlling ActiveSync device access on Exchange 2010 and Exchange Online and thought I would follow-up with quick post on how to accomplish the same results on Exchange 2013. For this post, I will create the same policy as before..  a device policy to quarantine any iPad devices. The use case for this scenario is that an organisation may for example allow users to choose whatever mobile phone they would like to use but block the use of iPads because these are not devices issued by the company. By quarantining a device, we can easily see who is attempting to use such a device, how many are out there and even decide to create a new policy specific to these devices.

To create a device policy, we need to access the “Mobile Device Access” option under the “Mobile” menu item in EAC. It should look something like this:

Clicking the “Edit” button will allow you to edit various settings. As you can see, I have decided to be permissive and allow all devices unless they are managed by a rule. You can select a distribution group or administrative account that will receive quarantine notification emails. You also have the option to add any custom or organisation specific text that will be included in the email notification sent to users when their device is blocked or quarantined.

We then click “+” under “Device Access Rules” at the bottom of the page to define our new rule. Here we can browse a list of all the devices and device families that have recently connected to our Exchange environment. Device family is a grouping of similar devices, in our case for example if we choose a Device family of “iPad” we can then decide to only apply this rule to iPad2 models or “All models” by selecting the appropriate device type. Lastly, we select our ABQ action:

Once we have clicked “Save” we should see the new device access rule listed under “Device Access Rules”

Once we have created the access rule, if any users attempt to connect using an iPad, they will be listed under “Quarantines Devices”

Users will receive a notification email similar to the following if they try to connect using an iPad:

Microsoft recently released Lync Basic 2013, a slimmer version of the Lync client that provides all the basic functionality available in the full version of Lync 2013. Some of the notable missing features in the basic client are advanced call features such as team ring, call forwarding, simultaneous ring, voice mail, call park, call delegation, response groups, and remote call control.

As usual for all things Lync related, my friend Greig Sheridan has a full write-up on his blog.

I am often surprised by how few customers know about or use ActiveSync device access rules (or ABQ for short) in Exchange 2010 when everyone seems to have the requirement to some degree or another. I see a growing trend to use third party products to do what Exchange can and has been able to do natively for a while now so I thought I would put together this post to go through some of the functionality offered by ABQ.

Before I continue, I would like to highlight the following two things:

1. Device access rules (ABQ) should not be confused with or is not intended to replace ActiveSync policies which are used to enforce things like device passwords, device encryption, etc. (click here for more on ActiveSync policies)
2. Everything described in this post also applies to Exchange Online

Depending on your requirements, you may decide to take a restrictive approach where you only allow a small set of tested and supported devices or be more permissive and only block/quarantine problematic devices. For this post, I will create a device policy to quarantine any iPad devices. The use case for this scenario is that an organisation may for example allow users to choose whatever mobile phone they would like to use but block the use of iPads because these are not devices issued by the company. By quarantining a device, we can easily see who is attempting to use such a device, how many are out there and even decide to create a new policy specific to these devices.

During the connection process, Exchange will follow a logical set of rules to determine the access state of each device and will either allow, block or quarantine the device based on the outcome. The sequence of challenges includes the following steps:

1. Is the device authenticated? If not, challenge for the correct credentials. Otherwise, go on to the next step.
2. Is Exchange ActiveSync enabled for the current user? If not, return an "access restricted" error to the device. Otherwise, go on to the next step.
3. Are the policy enforcement criteria met by the current mobile device? If not, block access. Otherwise, go on to the next step.
4. Is this device blocked by a personal exemption for the user? If so, block access. Otherwise, go on to the next step.
5. Is this device allowed by a personal exemption for the user? If so, grant full access. Otherwise, go on to the next step.
6. Is this device blocked by a device access rule? If so, block access. Otherwise, go on to the next step.
7. Is this device quarantined by a device access rule? If so, quarantine the device. Otherwise, go on to the next step.
8. Is this device allowed by a device access rule? If so, grant full access. Otherwise, go on to the next step.
9. Apply the default access state per the Exchange ActiveSync organisational settings.

The device policy that I am going to create will be applied at Step 7. To create a device policy, we need to access the “ActiveSync Access” options under “Phone & Voice” settings in the ECP. It should look something like this:

Clicking the “Edit” button will allow you to edit various settings. As you can see, I have decided to be permissive and allow all devices unless they are managed by a rule. You can select a distribution group or administrative account that will receive quarantine notification emails. You also have the option to add any custom or organisation specific text that will be included in the email notification sent to users when their device is blocked or quarantined.

We then click “New” under “Device Access Rules” at the bottom of the page to define our new rule. Here we can browse a list of all the devices and device families that have recently connected to our Exchange environment. Device family is a grouping of similar devices, in our case for example if we choose a Device family of “iPad” we can then decide to only apply this rule to iPad2 models or “All models” by selecting the appropriate device type. Lastly, we select our ABQ action.

Once we have clicked “Save” we should see the new device access rule listed under “Device Access Rules”

Once we have created the access rule, if any users attempt to connect using an iPad, they will be listed under “Quarantines Devices”

Users will receive a notification email similar to the following if they try to connect using an iPad. Note the custom text entered previously (red box)

One last thing to mention is that you do have the ability to make a personal exception for a specific user if needed, so for example if you have an executive who is adamant about wanting to use his/her iPad of if you decide after some time to test iPads this can be done without affecting anyone else. As always, full documentation can be found on TechNet