I have no problem with MSI file downloads. They are as simple as running an EXE. However, for reasons unknown, a lot of people don’t seem to like or understand downloading and running an MSI file; they feel more comfortable with EXEs. Visual Studio Setup projects turn your application into an MSI and a setup.exe file, which is inconvenient for distribution as generally online we want to provide the user with a single file download. Luckily there is a simple and free solution at hand in the guise of a quirky and little-known application included even as late as the Windows 7 base distribution called IExpress. This tool was originally created to enable branded deployments of Internet Explorer 6 (shocking, I know), but we can subvert it quite easily to our needs.

In the past few month the number of incomming request related to calendar issues increased. There are several reasons for this like message body truncation, Richt text or HTML formated messages get converted to plain text. Those are most likely related to iOS devices and there is a KB available for this here.

But not only iOS is causing issues. Especially when it comes to delegate scenarios with more than one delegate and when all of them have multiple clients with different versions (e.g.: Outlook 2010/2013, Outlook for Mac and a whole bunch of mobile devices).

To get to a point: Just ignored the following recommendations

• Best practices when using the Outlook Calendar
• Description of common scenarios in which Calendar information may be removed from the Calendar or may be inaccurate
• Recommendations for configuring delegate scenarios in outlook 2010

But how do you troubleshoot those issues? There are several techniques…

Exchange 2007 Management console doesn’t allow to use a mail-enabled public folder as a destination for transport rules, so the only way it’s make the rule from PowerShell.

In the following example we’ll create a Transport rule that sends a blind copy to a mail-enabled public folder for each message sent by a user.


$Mailbox = "user@example.local"
$PublicFolder = "PF1mailenabled-pf-01"
$condition = Get-TransportRulePredicate From
$condition.Addresses = @(( Get-Mailbox $Mailbox ))
$action = Get-TransportRuleAction BlindCopyTo
$action.Addresses = @(( Get-MailPublicFolder $PublicFolder ))
New-TransportRule -name "From $Mailbox Send A Bcc To $PublicFolder" -Conditions @($condition) -Actions @($action)


One of the frequent issues we see when supporting Small to Medium businesses (SMB) is replication issues caused by problems with physical Active Directory design. When I say “physical design” I don’t mean forests, tree roots, domains, child domains, etc. Those are elements of logical design. Physical design, in a nutshell, is how you configure the various elements in Active Directory Sites & Services. When these elements work harmoniously, Active Directory will reward you with fast & efficient replication. If mistakes are made, they’ll be compounded by the amount of replication traffic and at worst (typically in coordination with some other misconfiguration) can bring replication grinding to a halt. So let’s go over physical Active Directory design at a basic level.

The first rule of physical design is “You do not talk about Fight Club.” Wait a minute……wrong topic; my mistake. The first rule of physical design is to let…