LinkedIn Security/Information Risks with Exchange


Today after logging on to LinkedIn, I was greeted with a new screen I found rather worrying. It is commonplace for services like LinkedIn and Facebook to scan through your address book, and ask for credentials to do so (which is rather concerning already), but a new option has popped up:




This is asking for your work username and password. No 3rd party should be asking for corporate credentials like this, even more so a company that’s been hacked before . I tried this with a test account, entering the username and temporary password. It then asked for further information, which was the address for the Outlook webmail link and then connected and started showing contacts.

LinkedIn on this page says “We’ll import your address book to suggest connections and help you manage your contacts. And we won’t store your password or email anyone without your permission.” which is a start, but it’s just such a bad practise to get into, and encouraging people to do this is irresponsible of LinkedIn in my opinion. On top of this, it’s providing an easy mechanism for staff to mass extract their contacts outside the company, which many companies frown upon or even have strict policies in place.

You can’t stop people from entering in these details of course, but you can block the connection from working at the Exchange end, as long as you have at least Exchange 2010 SP1.

There are a few settings to check. First, under the Set-OrganizationConfig area, you’ll need to check that EwsApplicationAccessPolicy is set to ‘EnforceBlockList’. If it’s not, it’s going to be “EnforceAllowList” and you’re probably OK, as it’s using a whitelist for access to only what’s listed rather than a blacklist, to only block what’s listed.

Next, you need to add LinkedIn into the BlockList. This is done with the command “Set-OrganizationConfig -EwsBlockList LinkedInEWS

How do we know it’s the string “LinkedInEWS” to block? The IIS log files from Exchange will reveal this. After doing your test of trying LinkedIn (or any other Exchange Web Services connection) there will be a log entry. You can read this blog post from Microsoft for some great details but the abbreviated version is to look at what’s connecting fir POST /EWS/Exchange.asmx, and you’ll see the username you used to test, then the named connection. Here’s an example (with domain, username and IP changed):

2013-06-02 10:37:48 POST /EWS/Exchange.asmx – 443 domain\testusername LinkedInEWS+(ExchangeServicesClient/ 200 0 0 296

After applying, I retested and it seemed to still connect, but couldn’t find any contacts. My guess is that it’s authenticating OK, but then refusing to do much else. If anyone else would like to test this and post the results, I’d be very happy to find out update this.


Funnily enough, after writing this I found that LinkedIn had posted a very short version of the above:


Disabling Contact Import Process – Corporate IT Managers Instructions

How do I disable the ability for employees at my company to import contacts from their work email account?

Last Reviewed: 10/10/2012

Report Answer Inaccuracies

If you’re a Corporate IT manager, you can disable an employee’s ability to import contacts from their work email accounts.

Use Set-OrganizationConfig cmdlet to:

  • Set the value of config parameter EwsApplicationAccessPolicy to EnforceBlockList.
  • Add value LinkedInEWS to config parameter EwsBlockList.

For more information on using Set-OrganizationConfig cmdlet, please refer to Microsoft’s Managing Access for EWS Managed API Applications.


Further reading is available here:



Paul Cunningham has done a great writeup about this with some extra investigation and details, have a read:


Update 2:

This story had now been picked up by The Register, have a read here:


Update 3:

Seems to be getting picked up all over the place, so I’ll just keep updating this point as I find other articles. There’s some good discussion and opinions on this out there, such as why is Exchange configured to allow everything by default?

Exchange 2010 – Out of Office for HelpDesk


One of the pains of looking after Exchange 2010 is putting in an Out of Office message for someone who forgot to do it before they went away, and either can’t or won’t do it themselves remotely. If you’re lucky enough to be able to delegate this task out to others, you can easily do so with “Role Based Access Control”. There’s a nice built in group called ‘Help Desk’ which gives the members access to everyone’s Outlook Web Access Options (not their actual emails). These options include Out of Office as well as several other useful settings that are not particularly private or contain confidential information.

To do this, from the Exchange Management Console go to Toolbox > Role Based Access Control (RBAC) User Editor. This will bring up a web page that is a part of Outlook Web Access – log in with the relevant credentials for Exchange Administration, and you can navigate to the Roles & Auditing Section:


From this, you can double click on the Help Desk entry from the list of Role Groups, and add members to the list.

Once this is done, the users who were added to the group can access other user’s Out of Office by logging onto Outlook Web Access, going to Options > Set Automatic Replies. You’ll be greeted with this screen:

auto replies

From here, you can drop down the ‘Manage Myself’ menu and choose ‘Another User…’, select your user and you’ll see the selected users options screen, allowing you to set Out of Office.

Hope that helps!

Update 7th October 2014:

I had someone ask as the above didn’t work for them, but it was due to one of the Assigned Roles being removed against Help Desk. They should be:

Assigned Roles:
Message Tracking
User Options
View-Only Recipients

Exchange 2010 Unified Messaging – Unrecognised Voicemail Extension


I had an issue where a particular user’s voicemail on Exchange 2010 wasn’t working. When they called the voicemail number, they were asked “To access your mailbox, please enter the extension” rather than being greeted with their name and messages. The user was on Lync 2010, and Unified Messaging was enabled on their account with the matching extension number. Also, when dialing voicemail and trying to enter the extension number just met the message ‘XXX isn’t a valid mailbox’.

Disabling and re-enabling Unified Messaging made no difference. I was rather confident this was an Exchange/Unified Messaging issue, so I had the idea of checking ADSI edit to see if UM was properly enabled.

Checking the attribute “msExchUMEnabledFlags” found the issue. When a user has UM enabled, the value of this field should be 831, or 830 when disabled. I’ve come across this issue before, where it’s the wrong value and needs to be changed, but this was the first time I’d come across it as being 832.

Never a good sign when you google something, and you get zero results:


Changing the Attribute value back to 831 instantly fixed the issue, didn’t even require disabling and re-enabling Unified Messaging. If all else fails, change the value back to 830, refresh your Exchange Management Console and the user should show as being disabled for Unified Messaging, then re-enable as you normally would.

Hope this helps anyone else who comes across a similar issue.

Propagating User Folder Permissions on Exchange


This post is consolidating a lot of information I’ve found over the last day. It’s one of those things I’ve done a few times over the last several years, so each time I get to it I need a refresh!

For a user running Outlook connected to an Exchange server, and wanting to give someone else access to a large amount of existing folders, they really only have two options. Painstakingly go through every single folder’s permissions and add the other person, or set the permissions on a top level folder, then create new folders under that, and finally move the emails in. Permissions don’t inherit like normal file folders when you move one, only newly created folders inherit their parent’s permission.

Rather painful for the end user, but from the administration side of things, there are few options.

1. Give the second user full access to the first user’s mailbox. This option is far from ideal, because it’s an all or nothing permission, and it isn’t visible by the end user. They can’t tell who has access to their stuff. It also requires someone with appropriate Exchange privileges to manage and make these changes every time. It’s good for a generic mailbox, or someone who’s left the company etc where there is no particular user to manage the permissions.

Exchange 2003 instructions:

Exchange 2007 insutrctions:

Exchange 2010 instructions:

Exchange 2013 instructions:

2. Using either PFDAVAdmin or ExFolders, an administration can use a GUI to connect to a user’s mailbox and apply permissions to a folder, then force propagation of those settings to all child folders. This gives the user visibility and control of the current permissions and future changes, but also will save someone a lot of time from manually doing this.

For Exchange 2000 (sorry if you’re still on this!), Exchange 2003 and 2007, the PFDAVAdmin tool is used, available here: Keep in mind if you’re on Vista or above you’ll need to manually install Microsoft .Net 1.1. There are some great instructions here on how to do so:

How to apply the permissions and propegate? This blog post contains great detail, although you can just choose the option of all mailboxes and drill down to the one you’re after rather than worrying about long URLs:

For Exchange 2010, they change the utility to ExFolders, available here: . This one can only be run on your Exchange server, read the notes below the download.

Hope that helps anyone looking for a refresh on how to give mailbox permissions or propagate folder permissions!

Removal of Recovery Storage Group


Following on from my post here, once you’re finished with your Recovery Storage Group, you should clean it up. A rather simple process, you start with this Exchange Powershell command:

Remove-MailboxDatabase -identity <Server_Name>\<RSG_Name>\<Database_Name>

This will do the obvious thing of removing the mailbox database. If you can’t remember what you called your Recovery Storage Group, just use the command ‘Get-MailboxDatabase’ and you’ll see all your databases, and if you’ve named the RSG sensibly, you’ll be fine. One thing I ran into was trying this command from a Windows Server 2008 R2 box, while Exchange 2007 was running on Windows Server 2003. It brought up an error saying that I couldn’t remotely do commands from 2008 to 2003, but when I got onto the 2003 box, the database was gone! If you didn’t have this problem, you should get a message stating that you need to manually remove the database file.

The second step is to remove the Storage Group with the following command

Remove-Storagegroup -identity "<Server_Name>\<RSG_Name>"

Again, run ‘get-storagegroup’ to remind yourself of the name. After this, you’ll get a message telling you to remove the log file:

WARNING: The specified storage group has been removed. You must remove the log file located in h:\path\logs from your computer manually if it exists. Specified storage group: exchange\rsg.

Pretty straight forward. If you don’t clean up your RSG, you may have issues with backup software detecting the extra database.