Forcing Offline Address Book Updates

Recently a client was having issues with their offline address book (OAB). It hadn't been updating for several weeks. In this case, the source of the problem turned out to be the System Attendant service was stopped. This prevented generation of the OAB. However, as part of the testing process, I attempted to force an update of the OAB and that is how I found the error.

To update the OAB, you need to follow a multistep process:

1. Generate a new OAB.
2. Distribute the new OAB to the client access server.
3. Force the Outlook client to obtain the updated OAB from the client access server.

Normally the update process is done automatically and takes approximately 24 hours to complete. The detailed steps for forcing OAB update are below.

To generate a new OAB:

1. In the Exchange Management Console,  browse to the Mailbox node in the Organization Management workspace, and select the Offline Address Book tab.
2. Right-click the Default Offline Address Book and click Update.
3. In the Update dialog box, click Yes to acknowledge that it may take several minutes.

To distribute the new OAB to the client access server:

• Restart the Microsoft Exchange File Distribution service, or
• Run Update-FileDistributionService ServerName -Type OAB

To force the Outlook client to obtain the updated OAB from the client access server:

1. In Outlook 2010, click the Send/Receive tab.
2. Click Send/Receive Groups and click Download Address Book.
3. In the Offline Address Book dialog box, click OK to download the address book.

**If your Outlook 2010 client has multiple Exchange accounts the OAB that is updated is based on the mailbox you were in when you performed the update. You need to select a folder in the appropriate mailbox before downloading the OAB.

Additional Mailbox Remains after Full Mailbox Access Removed

Starting in Exchange 2010 SP1, when you are given Full Access to a mailbox, it is automatically added to your Outlook 2010 profile. Normally, I use the Exchange Management Console to add and remove Full Mailbox permissions. This works great for adding, but not so good for removal.

When you use the graphical tool to remove Full Access to a mailbox, it removes your permissions to the mailbox, but it remains in your profile. And just to make it interesting, you can't remove it from Outlook. You'll get an error when you attempt to delete it and it's not visible in the Outlook profile.

The error in outlook when attempting to close the leftover mailbox:

This group of folders is associated with an e-mail account. To remove the account, click the File Tag, and on the Info tab, click Account Settings. Select the e-mail account, and then click Remove.

The solution is to use the Exchange Management Shell to remove the permissions instead. When you do so, it removes the additional permission that adds the account to your profile.

Remove-MailboxPermission MbxName -User UserWithPermissions -AccessRights Fullaccess

Things I Learned From My Students This Week - Oct 19, 2012

Learning in class is not a one way experience. A good instructor is going to learn based on the experience of his/her students. Inspired by my students this week, I'm going to start putting up a list of things I learn each week from my students. So, with no further ado, here is this weeks list:

1. Alt+F4 closes the current window. Very handy when you have a ton of windows open and want them all to go away. Just keep whacking Alt+F4. Credit to Doug.
2. I've always struggled for an example when a desktop computer would have multiple network connections and therefore possible have  issues with multiple default gateways. This week a student pointed out that laptops could have wireless and wired connections at the same time. Seems obvious now that he said it, but for some reason it never clicked for me before. Credit to Doug.
3. Snap To option for a mouse automatically moves the mouse pointer to the OK button in a dialog box. I'm not sure whether this is good or evil yet, but I didn't know it existed before this week. Credit to Gord.
4. If you need to test antivirus software functionality, you can download the EICAR file. It is a file that is not a virus, but will be detected by antivirus software. You can download it from here: http://www.eicar.org/86-0-Intended-use.html. Credit to Mike.
5. The AHCI for hard drive configuration stands for Advanced Host Controller Interface. Credit to Mario, but fixed after fact check.

Install the SCOM 2012 Agent with PowerShell

I'm creating some lab activities and we're using the System Center 2012 - Operations Manager SP1. I'm not sure if this is causing our issue or we're just too low on memory in the VM. However, when I attempted to automatically deploy the Operations Manager agent to a Windows 2012 server, it was failing.

If you've done the deployment of the agent before, normally, when you deploy the agent a window opens that shows the deployment process. On my Operations Manager server, this window flickered then disappeared.

The solution for me in the short term was to use PowerShell to push out the agent. I used the following code:

$mServer = Get-SCOMManagementServer -Name server.domain.local
Install-SCOMAgent -Name target.domain.local -PrimaryManagementServer $mServer

If you have multiple computers that you want to deploy to at the same time, you can provide an array of computer names as a variable for the Name parameter in the Install-SCOMAgent.

Security Permissions for Event Log Forwarding

The default configuration for all of the Microsoft documentation related to event log forwarding indicates that you should use security based on the computer account of the computer that is collecting the events. From a security perspective, you need to add the computer account of the collector as an event log reader.
If you are collecting events from the security log, and use this basic configuration, you will get the following error:

Code (0x138C) Windows Event Forward plugin can't read any event from the query since the query returns no active channel. Please check channels in the query and make sure they exist and you have access to them.

This occurs because you need to assign addition permissions to allow the security log to be read by a computer. You need to:

• Add the Network Service local account to the Event Log Readers Group
• Modify the Manage auditing and security log User Rights Assignment to include the Network Service  local account and the event collector computer account. By default, this includes only the local Administrators group.

After configuring the security permissions, you need to restart the computer that is source of the events.

As you've seen this is a bit of a hassle. As an alternative, if you have a user account that has local administrative permissions on the event source computer then you can configure the event subscription to use that account instead. A user account with local administrative permissions already has the necessary permissions.

BCDedit Wierdness from PowerShell

I've started to standardize on using PowerShell instead of a command prompt for most activities, but every once in a while I run into odd things that don't work properly from the PowerShell prompt.

Today I'm doing some development on a course and it requires me to setup a host that boots to VHD. This is actually nice for courses because students work within the VHD rather than the original host OS. In theory, you could have independent classes setup with different VHD files.

Anyway, my issue was changing the description of a boot entry in the Boot Configuration Database with BCD edit. The syntax is this:

bcdedit /set {default} description "20415 Host 1"

However, I was getting the error:

The set command specified is not valid.

When I ran it from a command line it worked. It turns out that this is due to how PowerShell processes the curly braces. In PowerShell these are special characters. So, you can run it in PowerShell, but you need to escape the curly braces with backticks like this:

bcdedit /set `{default`} description "20415 Host 1"

Reducing Memory Usage for Symantec Mail Security

We have many clients using Symantec Mail Security for AV and Spam scanning for Exchange. The software is memory intensive and can cause problems on older implementations of Exchange 2003 where there is limited memory on the server. Each scan process (SAVFMSESp.exe) can use quite a bit of memory and there are multiple threads.

There are two ways to reduce memory utilization:

1. Reduce the number of scanning processes. I've seen each process consuming up to 400 MB of memory. So, less threads is good. The default is 3. In low volume environments, I've reduced this to 2 processes with no issues. Do this in the Mail Security for Microsoft Exchange Console on the Admin tab.
2. Reduce the memory used by each process. In the default configuration, each process uses as much memory as it likes and doesn't give it back. This makes sense on a busy server where that memory is in constant use, but on a relatively quiet server, you want that memory back for other processes. There are registry keys that you can use to set this.

To reduce the memory used by each thread on a 32-bit system, create the following keys as a DWORD in HKLM\Software\Symantec\SMSMSE\6.5\Server\Components\NaveSp\:

• ProcessUpperMemoryLimitInMB. This key specified the based memory usage for the thread. The thread can use more memory than this when actively processing, but it returns to this level. This value should not be set below 100MB. I typically use 128MB.
• ProcessMemoryCheckTimeInMin. This key specifies when the memory utilization of the threads is reduced. If you do not create and set this key, the default value is 5 minutes.

After changing the registry keys, you must restart Mail Security for Exchange.

Reference post from Symantec includes the path for 64-bit systems if required:

• http://www.symantec.com/business/support/index?page=content&id=TECH142829

Exchange 2003 Wrong Mapi32.dll

We are not sure how it happened, but a client that is still running Exchange 2003 experienced an issue today where System Manager could not be started. When you started it, there was an error about the incorrect version of mapi32.dll. However, to the best of our knowledge the version of mapi32.dll had not changed.

I did notice that mapisvc.inf had changed this morning and I suspect that was the cause of the wrong mapi32.dll being used. However, we don't know why that file was updated.


The fix was relatively easy I copied mapi32.dll from C:\Program Files\Exchsrvr\bin to C:\Windows\System32. This is done normally as part of the Exchange 2003 installation process.

Full text of the error was:

Exchange detected that "c:\windows\system32=MAPI32.DLL" is not the
correct version required to run Exchange System Manger or Exchange Server
2003. This may cause failures in Exchange System Manager, affect
availability of your server, or both. For more information see Microsoft
Knowledge Base article Q266418 at http://support/microsoft.com

 In most cases, this error is the result of installing Outlook on an Exchange 2003 server and the Outlook mapi32.dll overwrites that from Exchange. That was not the case here.

For more information:

• http://support.microsoft.com/kb/266418

Grid Lines in RDP Session from Windows 2003 to Windows 2008 R2

In the midst of doing a server migration I was using RDP from a Windows 2003 server to a Windows 2008 R2 server. When I connected, there were annoying grid lines that make it awkward to read the screen. Easy fix though. Just download a newer version of RDP client for Windows 2003.

• http://www.microsoft.com/en-us/download/confirmation.aspx?id=21296