27 January 2016

Messages that are sent by using the "Send As" and "Send on behalf" permissions are copied only to the Sent Items folder of the sender

This is something i didn't know existed but keeps popping up as a frequent question in our organisation.

An outlook user with access to a shared mailbox, send as or send on behalf of rights sends an email from the shared mailbox, but the sent email doesn't get saved in the shared mailbox sent items folder but in the users sent items folder.

Since Exchange server 2010 SP2 update roll-up 4 it's possible to specify where the sent emails will be saved. This also goes for Exchange server 2013 CU9 and up.

First check the current settings for a shared mailbox:

Get-MailboxSentItemsConfiguration -Identity sharedmailboxname

RunspaceId                  : 2d911aef-3416-42f9-9900-531d0fcdea94
SendAsItemsCopiedTo         : Sender
SendOnBehalfOfItemsCopiedTo : Sender
Identity                    :
IsValid                     : True
As you can see the "SendasItemsCopiedTo" and "SendOnBehalfOfItemsCopiedTo" is set to "Sender"
There are 2 settings to choose from: "Sender" "SenderAndFrom".

To set it to save in both mailboxes use:

Set-MailboxSentItemsConfiguration -Identity sharedmailboxname -SendAsItemsCopiedTo senderandfrom -SendOnBehalfOfItemsCopiedTo SenderAndFrom
Check to be sure:

Get-MailboxSentItemsConfiguration -Identity sharedmailboxname

   RunspaceId                  : 2d911aef-3416-42f9-9900-531d0fcdea94 SendAsItemsCopiedTo         : SenderAndFrom SendOnBehalfOfItemsCopiedTo : SenderAndFrom Identity                 IsValid                     : True  

Set it to all shared mailboxes in a nice one liner for Exchange 2010:
Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails sharedmailbox | Set-MailboxSentItemsConfiguration -SendAsItemsCopiedTo SenderandFrom -SendOnBehalfOfItemsCopiedTo SenderAndFrom

Set it to all shared mailboxes in a nice one liner for Exchange 2013:
Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails sharedmailbox | Set-Mailbox -MessageCopyForSendOnBehalfEnabled $True -MessageCopyForSentAsEnabled $True

Source 1
Source 2

26 January 2016

Lync/Skype addressbook cannot be downloaded

This seems to to happen very often, and rumor has it that it's a bug Microsoft hasn't addressed yet.

The addressbook can't be downloaded for some reason, and gives the above error.
There's a pretty simple way of getting rid of it according to this post by Jeff Schertz.

First check your current Global Policy settings:

The idea is to only let it do a websearch.

Create a new CLientpolicy:
New-CsClientPolicy -Identity AddressBookClientPolicy -AddressBookAvailability WebSearchOnly

The assign it to a user to test it:
Grant-CsClientPolicy -Identity Username -PolicyName AddressBookClientPolicy

To find all users that have no Clientpolicy set:
(Get-CsClientPolicy -Identity ChicagoClientPolicy).psobject.properties |? {$_.value}| select name,value

Now to see all this in action on a Lync\Skype client.
Log off from Lync\Skype.
Go to %userprofile%\appdata\Local\Microsoft\Office\16.0\Lync and delete the GALcontacts.db and GALcontacts.db.idx files.
(You may want to check other folders depending on your Lync Skype version.)
Now log back on a gain. Voila the error is gone, and all your searches go through the Address book on the server, with the big advantage of it always being the most up to date version.

10 January 2016

Lync 2010 Topology builder unable to download Topology

Sound familiar?

"The term 'Get-CsTopology' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again."

It doesn't really say very clearly in the error that it can't find and thus load the Lync module, but it is what it's trying to tell you.

Copy the Lync module from:
C:\Program Files\Common Files\Microsoft Lync Server 2010\Modules\Lync


And start the Topology builder again. Now you can download the topology as you normally would.

05 January 2016

Unable to renew SubCA - 0x8007139f (WIN32: 5023)

It's the most wonderful time of the year, renewing your Issuing, Intermediate, SubCA of however you want to call it.
So the time has come to renew the Issuing certificate, well for me it has, and as always i pull out the documentation because i wanna do it correctly.
But as you all know (you have to know this) since January 1st SHA1 has been deprecated and we all should move to SHA2 (SHA256).

Obedient as i am, i moved our CA to SHA2. No problem there. But...
Now is the season to be renewing your Issuing certificate and this happens.

The following steps are to be followed:

Steps to Renew if Root CA is offline
  1. Log onto your Issuing CA and open the Certificate Authority MMC
  2. Right click on your Issuing CA > All Tasks > Renew CA Certificate
  3. Press Yes to Stop AD Certificate Services
  4. Press No to Generate a new Public/Private Pair
  5. Press Cancel and save the request some where C:\Temp for instance
Now in my case step 5 didn't happen.
Running CertUtil gave an error that was not really clear why things weren't working as expected.

After digging around for hours on fora's websites and going through my documentation over and over, it suddely hit me.
I had moved to SHA2, and the certificate i tried to renew was based on SHA1.
This would never work, so long story short. Moved to SHA2 recently? New private key in your Issuing certificate request, and follow the route to renew your Issuing certificate as you always would.

Next thing to note is that all your current certificates have to be regenerated to be compliant to the new Issuing certificate (SHA2), as for the RootCA that doesn't need to be SHA2, Trusted root certificates using SHA1 are not affected. Clients trust them for identity purposes and not for the strength of their signature algorithm.