IT

Full Mailbox Access to All Mailboxes in Exchange 2010

Posted on by Adam Fowler

I’ll start this out by saying ‘Full Mailbox Access to All Mailboxes’ is generally a bad idea. It should be done on demand with the appropriate approvals and paper trails, but there are times when this may be needed – for example a service account for 3rd party software that has to read or add things to everyone’s mailbox in the company.

In my last post “End User Management of Distribution Groups in Exchange 2010” I explained how the new Role Based Access Control (RBAC) worked. Although this can be used to configure many things, it won’t give you full access to a mailbox as it’s an Active Directory based permission.

You can manually do this on a per mailbox level by either using the Exchange Management Console, or the Exchange Management Shell by following the Microsoft Technet documentation here and it’s fairly easy to convert this to all mailboxes in powershell, but that won’t help you with newly created mailboxes after running the command.

Yes you could run a daily task to get around that, but an alternative is giving AD access at the database level. Any existing or newly created mailbox will get permissions this way.

So, with that all in mind, the Exchange Powershell command to run on a particular database is:

Get-MailboxDatabase -identity “[mailbox database name]” | Add-ADPermission -user [username] -AccessRights GenericAll

If you don’t know what your databases are, just run ‘Get-MailboxDatabase’ or if you want to just apply the permissions to all databases:

Get-MailboxDatabase | Add-ADPermission -user [username] -AccessRights GenericAll

You can apply this to a AD group rather than a user which I’d suggest (no changes to the command required apart from typing the group name rather than user name), because it’s then easier to manage the members of the AD group than re-run this command. Also if you apply the settings to a particular user, and that user launches Outlook, all mailboxes they have full access to will auto-load into their Outlook session. Not ideal if you’ve got hundreds!

If you’d like to know more about the Add-AdPermission command, and the possible AccessRights settings check out this Technet article.

End User Management of Distribution Groups in Exchange 2010

Posted on by Adam Fowler

After migrating from Exchange 2007 to 2010 and addressing all immediate issues, we eventually hit a new issue. Managers of Distribution lists who previously could add and remove members, now couldn’t do it!

savedChanges to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object.

So, why would this break going from Exchange 2007 to 2010, and why would there be a delay?

Role Based Access Control (RBAC) was a new feature introduced in Exchange 2010 which changed the way a lot of security worked. There’s a greatly detailed 4 part article from msExchange.org here http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/exchange-2010-role-based-access-control-part1.html which explains this in detail.

As far as the groups are concerned, they stay in a 2007 mode until they get updated. When updated (by something like adding/removing a member) you’ll get prompted about changing the object:

To save changes on objectTo save changes on object “Silly name”, the object must be upgraded to the current Exchange version. After the upgrade, this object cannot be managed by an earlier version of hte Exchange Management Tools. Do you want to continue to upgrade and save the object?

Once you do this, that particular object (distribution group) now runs under the new RBAC security settings.

By default, the RBAC security settings out of the box don’t allow anyone to be able to add or remove members to distribution groups. The Exchange Team Blog explains this perfectly here: http://blogs.technet.com/b/exchange/archive/2009/11/18/3408844.aspx and also leads onto a script which will probably set things up how you want. If you don’t read this carefully, you may end up applying the built in ‘MyDistributionGroups’ role to the ‘Default Role Assignment Policy’ which means everyone can create distribution groups – definitely not ideal in most environments. I started reading another blog post which said to do exactly that, but didn’t explain why or how it worked. Sure it fixes your immediate issue, but you’re opening up a lot more than what you should.

So it’s a fairly easy fix once you now how, but if you haven’t had to worry about RBAC before there’s a little bit to get your head around first before ticking boxes and hoping for the best.

A big thanks to @ExchangeGoddess and @24x7ITConnect for their assistance and guidance on this information.

SCCM 2012 R2 Slow Imaging Fix

Posted on by Adam Fowler

Microsoft have released on 8th November 2013 a hotfix for SCCM 2012 R2, KB2905002. Unless you’re not using SCCM for imaging, this hotfix is a must. This fix fixes two seperate issues. The first which I’ll copy verbatim from Microsoft’s site is:

After you enable the PXE Service Point role on an instance of a specific distribution point, or you select the Deploy this boot image from the PXE-enabled distribution point property of a boot image, the Windows Deployment Service (WDS) stops running.

Pretty major bug. The second fix everyone would have noticed is around the slowless of deploying an image (a.k.a. OSD) from R2. It’s rather slow! Again, verbatim:

When operating system image files are downloaded to Configuration Manager 2012 R2 clients, you may find that the download takes longer than it did in previous versions of Configuration Manager 2012 clients. You may see this behavior when the target client is running Windows PE or a full Windows operating system.

You can download the fix from http://support.microsoft.com/kb/2905002 and the fix needs to be installed on pretty much any SCCM server you have. It will nicely create packages if you have lots of servers to push it out to, or you can just do it manually per server. It will stop and start services, and ask you to restart after installing in most scenarios so keep this in mind.

Distribution Points don’t need the update, even if they’re running as a PXE Service Point. You can’t run it on one (I tried!).

You’ll also need to run the hotfix against any PC running the console as there’s an update for that too.

Thanks yet again to @nickstugr for alerting me to the update.

Update 12/11/2013 – Confirmed that the patch has put deployment speeds back to how they once were.

Windows 8.1 Uptake Will Be Slow for Enterprise

Posted on by Adam Fowler

Opinion: Windows 8.1 was officially released on the 18th October 2013. Many people had their hands on it a few weeks earlier, due to Microsoft releasing the RTM version to Technet and MSDN subscribers. People have been waiting for this release, especially with the mixed press around Windows 8. Windows 8.1 seems to address a lot (but not all) of the general complaints out there in consumer land, but for Enterprise it’s a different story.

Windows 8.1 fixes several key complaints – The start button is back to try and lessen the blow in changing how stuff works for users, the Windows App Store now supports a proxy using NTLM Authentication (yes, TMG/ISA!) and many other benefits.

The big show stopper is going to be Internet Explorer. This is one of the main reasons XP has lasted so long in the Enterprise space, when so many companies were stuck with IE6 and couldn’t jump to Vista (OK, nobody really wanted to for other reasons too) as Vista came with IE7 and couldn’t be downgraded. Windows 7 had the same issue, out of the box you get IE8. All it takes is one key Enterprise application that doesn’t support anything above IE6, and you’re stuck on XP until that issue goes away. Now maybe the application works on something newer, but if you run into any issues your huge support dollars are useless, as you’re now running it in an unsupported way.

IE6 finally started to die off and everyone’s now been jumping to Windows 7. The Windows 7 jump forced IE8 onto everyone, and most Enterprise applications touted IE8 as the new standard browser they supported. All was well for a while, and in the meantime IE9 and IE10 were released.

Software developers have been getting better at this overall, and usually IE10 will now be a supported browser. IE10 had been coming since April 2011 and was released September/October 2012 for Windows Server 2012/Windows 8 respectively, and then Windows 7 February 2013. That’s a long window for software developers to start getting on board and supporting it.

Often for support, a product upgrade is required. This can set back a company a reasonable amount, depending how complicated, costly and time consuming the upgrade is – and how other projects are affected.

Windows 8 was brand new when IE10 came out, but Enterprise generally held off due to the major UI change for users, waiting for Windows 8.1 to fix it.

Jump forward to June 2013, and IE11 is first released as a developer preview. Only 3 months from that, and it’s now bundled in with Windows 8.1 and Windows Server 2012 R2. This is an incredibly small window in comparison to IE10, so hardly any developer will support this for quite some time (many are still catching up to IE10).

So where does this leave the SOE for an Enterprise? Stuck on Windows 7. They don’t want to jump to Windows 8 because 8.1 fixes so much, but they can’t jump to 8.1 either because hardly any Enterprise applications will support the default IE11.

Why not just use another browser? Firstly, you need to use one that all the software developers support, and then you’ll run into similar issues around version support and control. Just because Google Chrome does lots of little updates doesn’t make it more stable, you don’t know which next update could potentially break a function, and again you’re stuck with no support by running a version higher than what’s officially recognised.

Why not just use a different software developer? Enterprise applications are often aimed at particular industries, and often there’s a single leader. That generally means you have to start losing functionality, spend huge dollars and time to move away from the product you’ve used, get all your staff retrained and so on. From someone up top, this just seems like a waste of money if you’ve got something that works now.

So, what’s the real solution here? Hopefully competition will play a factor where more versatile software developers can make great products and beat the slower moving ones, but that often takes a long time to occur (the speed of a glacier comes to mind). Solutions like Citrix XenApp or Microsoft App-V for deploying a sandboxed browser to run the app virtually/hosted is a decent workaround, but adds extra complexity.

I think out of necessity, existing software developers will start to adapt faster. Microsoft’s model is moving towards yearly updates for all their products, and that will keep getting shorter and quicker to keep up with the newer players to the industry. Customers will start making this sort of support as high up on the list of demands, rather than asking and accepting what they’re given.

Windows 7 will still be seen as the new XP for a while, but we shouldn’t see such a huge % of Windows 7 PCs out there when it’s life span comes to an end (2020 if you were wondering).

It is still a long way off, but compared to where we are now versus several years ago, we’re doing a lot better. Windows 8.1 will get there, but not until all the legacy apps support IE11.

Update 04/11/2013 – Interesting writeup from Michael Stum, from his website ‘Not Rocket Science’ called “Google Chrome is not usable in a corporate Windows environment” http://stum.de/2013/11/01/chrome-is-not-usable-in-corporate-windows/ – thanks @nickstugr for the link!

More LinkedIn Security Risks with LinkedIn Intro

Posted on by Adam Fowler

LinkedIn have just announced a new way they’ve engineered LinkedIn user information into the native iOS mail reader. Have a look at the article here: http://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios#!

In principal, this is an interesting idea – it’s what CMS (Customer Management Systems) have been doing for a long time, which is integrating a database of users/companies into your emails so at a glance you go from email address to user profile to company all in the one spot.

From a user perspective, this is quite neat. Seeing where someone works as part of the email, their job title, other connections saves a lot of time and brain energy when they’re thinking ‘who is this guy?’ – but from a security standpoint this is bad.

LinkedIn’s whole quote on the privacy aspect of this is:

Security and Privacy

We understand that operating an email proxy server carries great responsibility. We respect the fact that your email may contain very personal or sensitive information, and we will do everything we can to make sure that it is safe. Our principles and key security measures are detailed in our pledge of privacy.


That doesn’t say much, apart from ‘Come on.. trust me!’. Firstly, you’ve got to give LinkedIn your email password. Check my previous article as to why this is bad: http://www.adamfowlerit.com/2013/06/02/linkedin-securityinformation-risks-with-exchange/ – a pledge of privacy isn’t going to help you after a catastrophic event.

So, this method is actually worse again. All your emails traverse via LinkedIn’s proxy service, the email gets modified then delivered to your iOS device. Emails are insecure by nature as they traverse the internet in plain text format (excluding things like PGP and other encryption methods that most people/companies don’t use), but having them centrally filtered via a 3rd party means you’re giving them a truckload of information about yourself, who you deal with, your email habits and so on.

Would your company be happy with a 3rd party that you have no agreement with, receiving and forwarding on all your emails? Even if the emails aren’t stored, if LinkedIn was breached again (which they have been before, multiple times), other people could obtain anything from your contacts, to your password and email contents.

oAuth is supported too, which is a safer approach as it can be revoked – but you’re still giving the same level of access while the connection is approved.

Luckily for Exchange administrators, that doesn’t seem to be supported yet according to https://intro.linkedin.com/micro/faq but for Google Apps people, you’ll need to look into how this can be blocked if you want to. If you’ve found out how, I’d be happy to add it to this post.

Update: There is a great writeup from Bishop Fox on several great reasons as to why this is a ‘bad idea’ http://www.bishopfox.com/blog/2013/10/linkedin-intro/