I was recently asked to help out with an OCS video conferencing issue whereby peer-to-peer video was working fine but as soon as a third person was added to the session making it a conference the following error occurred:

Cannot perform the selected action. This action may not be permitted by the conferencing service. Please try again. If the problem persists, please contact your system administrator.

Not the greatest error I’ve ever seen. Multi party video conferencing should work out of the box with OCS so I suspected firewall policy as the main culprit seeing as traffic converges at the OCS server (standard edition in this case) or pool once more than two people are in the conference.

As usual the real detail can be found in the Communicator client tracing logs. I managed to track the problem to this error in the logs:

ms-diagnostics: 7014;source=”domain.com”;reason=”Error parsing SDP: Invalid ICE transport candidates”;component=”AvMcu”

After a bit of investigation I managed to track down an entry in the OCS group policy called Disable Interactive Connectivity Establishment (ICE) which was Enabled.

The description of the policy states the following: Disables Interactive Connectivity Establishment (ICE). When enabled the ICE protocol provides a way to establish voice or audio/video calls between clients separated by a Network Address Translation (NAT) layer or firewall.

After setting this back to Not Configured, refreshing policy and restarting Communicator, multi-party video began to work perfectly. So it seems OCS needs ICE to work correctly, even when there is no NAT in place on an internal network? In this case it seems as if some over zealous policy settings upon design/install caused this to stop working.

There are two ways in which to do this; one is the administration portal for your Office 365 deployment and one is using the Microsoft Online Services Module for PowerShell. The first is a bit boring and straight forward. The second at least gets you inside the management shell so helps you to start learning how to harness the power of PowerShell with Office 365.

Office 365 Administration Portal

1. Login to your Administration portal at https://portal.microsoftonline.com/
2. Click on your company name in the top left right above where it says ‘Admin Overview’.
3. Click the Edit button.
4. Change the Primary Verified Domain using the dropdown box.
5. Click OK and then Close. Done.

Microsoft Online Services Module for PowerShell

1. First of all you need to install the Office 365 CmdLets. Go here and follow the instructions to install the modules based on your OS:
   http://onlinehelp.microsoft.com/en-us/office365-enterprises/2b09b6a8-ad7e-446f-b7f0-273856beed70#BKMK_install
2. Load up the Microsoft Online Services Module or import the module to your current PowerShell session using the instructions here:
   http://onlinehelp.microsoft.com/en-us/office365-enterprises/2b09b6a8-ad7e-446f-b7f0-273856beed70#BKMK_connect
3. Type the following and hit Enter.

   Connect-MSOLService

4. Type your Office 365 credentials in the box that pops up and hit Enter.
5. Type the following and hit Enter.

   Set-MsolDomain -Name mattellis.me -IsDefault

6. Done

I’ve recently setup a simple Office 365 deployment but instead of buckling to Microsoft and moving the DNS to their servers I wanted to set it up using my existing registrar for the DNS. The GUI at Office 365 doesn’t exactly make this crystal clear so I thought I’d show the steps involved in sorting it out.

First, you need to add the custom domain to Office 365 and verify that you own it.

1. On the Admin page, under Domains, click Add a domain.
2. Type your domain and click Next.
3. Go through the steps in order to verify your domain. The easiest way to do it is with a TXT record. They’ll give you a TXT record to register in your domain’s DNS that can be looked up by Microsoft to verify you own the domain.
4. Once you’ve added in the TXT record (or used an MX record if that’s what you decided to do) then click the Verify button. Depending on your DNS hosting provider, publication of the TXT record can take anything from a few minutes to 72 hours (although a few hours is most likely).
5. If everything was entered okay, your domain will be verified. Now, click Cancel. Your domain will remain verified but you will not proceed to the part where you update your DNS name servers to be the Microsoft ones.
6. How you need to enter the correct DNS for your domain at your own DNS hosting provider. The list of DNS entries needed for Exchange Online and Lync Online are as follows (the custom domain name I’m using in the example below is mattellis.me):

Easy peasy.

I stumbled upon a little problem the other day when I was asked to change someone’s Out Of Office (OOF) message. After doing this I was notified that the OOF note showing in Communicator had not changed.

After troubleshooting a perfectly working Exchange availability service for an hour I found out that this is by design.

Took a bit of searching but found the following information on this page:
http://office.microsoft.com/client/helppreview.aspx?AssetID=HA102067221033&ns=COMM2007&lcid=1033

The Out of Office note will replace any Personal Note you have previously entered, but the Out of Office note will not be updated until you sign out and sign back in to Communicator. Once you have done so, the note can take as long as 30 minutes to propagate through the Presence system. In addition, you must be running the Communicator client on a device that can connect to Exchange in order for this information to propagate.

So, the OOF note is only created after the user has logged back in to Communicator, pulled the new OOF from the Availability service (or Public Folders depending on your setup) and then put this back into the Presence system.

We recently introduced and zero day policy for leaver mailboxes but in doing so we realised that EV couldn’t archive mailboxes that were hidden from the GAL or disabled. This wasn’t very good for a policy that was meant to archive mailboxes of disabled and hidden users…

After a bit of googling I found that we could do this with a couple of registry keys and I can report that it works pretty well:

HKLM\Software\KVS\Enterprise Vault\Agents
ProcessHiddenMailboxes = 1 (DWORD)

HKLM\Software\KVS\Enterprise Vault\Agents
ExcludeDisabledADAccounts = 0 (DWORD)

Don’t ask me why each one is a different way round logically – go figure..?

Anyway, this worked for me on version 9. I’m told it works for version 8 too…

For those of you disappointed when Lion came out to find that anything later than version 13.0.0 of Communicator for Mac was basically unable to do anything (and I mean, anything) on Apple’s new OS, there is finally a fix from Microsoft.

Get it here: http://www.microsoft.com/download/en/details.aspx?id=26835

Adjusting the delivery restrictions on distribution groups is quite a common task. The more members a group has the more of a problem this ends up being in big organisations.

Setting the permissions in the Exchange Management Console (EMC) is simple enough when you have one or two people/groups to add to the allowed list. When you have many user/groups needing to be added across a massive range of groups then this is something your going to need to script.

Now this is where it doesn’t quite work as expected. It’s easy enough to create a shell command to add multiple users to the -AcceptMessagesOnlyFrom attribute on the DL object but when doing this you’ll find that only the last one in the list has been added. This is because the attribute is an array. You can view this using the following command.

Get-DistributionGroup -Identity "GROUP-NAME-HERE" | Select -expand AcceptMessagesOnlyFrom | ft Name</em>

To add a new user to this list you have to call the already existing list and then add the new user to the end of it. Because PowerShell is so, well, powerful you can do this quite easily with one one-liner:

Set-DistributionGroup "GROUP-NAME-HERE" -AcceptMessagesOnlyFrom((Get-DistributionGroup "GROUP-NAME-HERE").AcceptMessagesOnlyFrom + "IDENTITY-OF-USER-OR-GROUP-HERE")

The identity of the new group or user can be in the form of the following attributes:

• Distribution Name (DN)
• Canonical Name
• GUID
• Name
• Display Name
• Alias
• Exchange DN
• Primary SMTP Email Address

Now, that’s all very well, but what if you’d like to add multiple users to multiple groups? Here you go – just stick the groups you’d like to amend and the users to be applied to those groups in the text files.

$People = gc C:\People.txt
$Groups = gc C:\Groups.txt
ForEach ($Group in $Groups) {
   Set-DistributionGroup $Group -AcceptMessagesOnlyFrom((Get-DistributionGroup $Group).AcceptMessagesOnlyFrom + $People)
}

Works well huh?

This is more of an annoyance if anything but I noticed today that while I could look on the Properties page of each mailbox database and see the LastFullBackup date and time this wasn’t reflected in the Get-MailboxDatabase -Server “SERVERNAME” | fl command. It was simply empty.

It seems that if you’d like to get details such as LastFullBackup, Mounted, BackupInProgress or OnlineMaintenanceInProgress you need to use the -Status parameter.

So, my command should have been:

Get-MailboxDatabase -Server "SERVERNAME" -Status | fl

I don’t know why, but that’s the way it is.

There’s not a massively easy way of checking for the active node of a cluster without manually going into Failover Clustering or into the properties of the cluster in the EMC. Get-ClusteredMailboxServerStatus will give you the active node by getting the OperationalMachines attribute but if you’d like to use this in scripts or display it in a nice format then it’s not in the most helpful format (it’s an array). It usually looks something like this:

{NODE1, NODE2 <Active, Quorum Owner>}

Using the following script we can retrieve all the clustered servers, then run Get-ClusteredMailboxServerStatus on each one and extract the active node from OperationalMachines attribute based on whether “Active” exists in the array.

NB. This must be run on a machine that has failover clustering feature installed (so, one of the nodes probably) – that’s the only annoying thing.

Here’s the code:

$Clusters = Get-MailboxServer | ? {$_.ClusteredStorageType -ne "Disabled"}
ForEach ($Cluster in $Clusters) {
   $ClusterStatus = Get-ClusteredMailboxServerStatus -Identity $Cluster.Name | Select -Expand OperationalMachines | ForEach {If($_ -like "*Active*") {$_}}
   $ActiveNode = $ClusterStatus.Split(" ")[0]
   Write $ActiveNode
}

Cheers!