Exchange 2010 and 2013 have an option called “Retention Policies”. I’ll base the below on what I see for Exchange 2010, but most of not all should apply to 2013 also. Retention Policies are useful if you need to keep your user’s mailboxes clean, as well as trying to avoid a Deleted Items folder with every single email the employee has received in their time with the company. You can work out what the company agrees with for what can and can’t be auto deleted, and save a lot of money on space for both live information and backups. The Retention Policies are made up of “Retention Policy Tags” and these tags “control the lifespan of messages in the mailbox” as quoted by one of the wizards that you configure this in mailbox. The Retention Policy is then targeted at the mailboxes you want to apply these settings to. Maybe not this wizard. It’s worth noting that a mailbox can only have one Retention Policy linked to it, so you need to plan overlapping settings accordingly. So, what can a Retention Policy Tag do? You give it a ‘Tag Type’ which is either a folder in someone’s mailbox (e.g. Deleted Items) or every other folder that isn’t an inbuilt folder. From that definition of what folder the tag is on, you can either set an age limit for all items in that folder, or set the items to never age. The Age limit is a number in days. This number actually means something different depending what Tag Type was targeted. For an email in the Deleted Items folder, it’s based on the date the item was deleted by stamping it at the time of deletion. There’s some caveats around that, so refer to this chart on TechNet which lays out...

Originally posted on adamfowlerit.com 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 http://www.pcworld.com/article/257045/6_5m_linkedin_passwords_posted_online_after_apparent_hack.html . 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...

Lync 2010 with Enterprise Voice attaches a phone number to a user with a direct one to one relationship. This means that when a user departs, the account should get disabled along with any Lync attachments. In turn, this abandons the phone number that was attached to the user. All great by design, but what about external people that are still calling the number of the departed user? You could leave the user’s Active Directory account disabled, leave Lync attached and configure it that way, but that’s a big hassle. Microsoft covers this scenario with a feature called “Unassigned Number”. Unassigned Number lets you configure an Announcement on an entire number range. The idea is that if any extension in the number range configured (which can be a single number) is called and isn’t attached to a user, it will divert the call to either an Announcement or an Exchange UM Auto Attendant number. Generally just the Announcement is fine, because the Announcement can be configured to be nothing, but divert the call to wherever you want it to go afterwards. The Announcement needs to be configured before you create an Unassigned Number Range, which can only be managed by PowerShell. The Unassigned Number Range can be created via the Lync Control Panel GUI or PowerShell which seems a bit inconsistent. Creating an Announcement is rather easy still, with a great guide from TechNet here. The important bits are to give your Announcement a name, tell it which Lync Pool to use and give it a target SIP address to send the call to. An example command do this is: New-CsAnnouncement -Identity ApplicationServer:lyncpool.mydomain.com -Name "Forward Announcement" -TargetUri sip:reception@mydomain.com Note that if you use a direct phone number for the sip address, you need to append...