Ben’s Tech Blog

We had a user contact us yesterday who had deleted a public folder that contained a large number of subfolders and items. This is not usually too much of a drama, we have a 14 day deleted items retention period on our public folder stores, so its usually just a case of adding the DumpsterAlwaysOn key to the registry on the client, browsing to the parent public folder, clicking on Tools, then Recover Deleted Items and selecting the folder to recover. This time however, we received the following message when attempting to recover the folder:

“Outlook was unable to recover some or all of the items in this folder. Make sure you have the required permissions to recover items in this folder, and try again. If the problem persists, contact your administrator.”

Naturally, we checked the permissions; in fact we tried to use the Exchange service account mailbox to recover the folder but received the same error. We also tried temporarily disabling Trend ScanMail (our Exchange level antivirus) in case it was interfering with the recovery process. The folder would actually appear in Outlook temporailly before it produced the error, at which point it would disappear again.

We did a lot of searching around to find a solution; most forums and articles that we came across either suggested to check permissions and disable the antivirus like we had done or use isinteg to repair the database (which I’m not such a fan of). Others suggested that it wasn’t possible to recover the folder at all. After some more searching I came across a tool called MFCMapi.

Once I downloaded MFCMapi, I was able to browse the folders that had been deleted. I tried to recover the folder that the user had deleted, but it produced an error. However, because I was able to browse the sub folders, I attempted to recover one of the them and it was successful. I tried several folders, some were successful and others were not. I figured if we could get some of the contents back it would be better than nothing. It appeared that some of the contents were corrupted, which would explain was why Outlook was unable to recover the folder. Outlook doesn’t provide the option to recover the sub folders, and this is where MFCMapi really helped. I was able to restore the majority of sub folders with 5 or 6 of them not wanting co-operate.

You can download MFCMapi from here.

Once downloaded and extracted, run MFCMapi.exe and close the welcome window. To browse deleted public folders do the following:

1. Click on the Session menu and click on Logon and Display Store tables. You’ll see that it uses Outlook to connect to the stores, select your Outlook profile and click on OK

2. Click on the MDB menu and select Open Public Folder store. Tick the Use Admin Privilegesbox and click on OK.

3. Expand Public Root and IPM_SUBTREE. You’ll then see the public folders that you would normally see under “All Public Folders” in Outlook.

4. Navigate through the public folder tree until you get to the parent folder of the folder that you are trying to restore.

5. Right click on the parent folder and select Open Deleted Sub Folder Table. A new window will open displaying the deleted subfolders. Right click on the folder and select Restore Deleted Folder. A box will open up that allows you to select to also restore the subfolders, tick that option and click on OK. You may receive an error message stating that the folder couldn’t be restored, much like I did.

If you don’t receive the message then the restore was successful and you should see the public folder and items appear in Outlook. If not, don’t panic just yet, you may be able to restore some (hopefully most) of the subfolders. If this is the case, just navigate through the folder structure and attempt to restore each folder. Unfortunately it doesn’t allow you to select multiple folders using CTRL or SHIFT; I spent a fair bit of time restoring each folder one by one.

Considering that I was able to restore most of the folders and items that had been deleted, I was happy with the result, and so was the user. MFCMapi proved to be a very useful tool and I’m sure there will be times when I’ll need to use it again.

We have been running Cisco Call Manager for some time now as well as the Cisco Attendant Console software. Recently, the users of the company that we have merged with moved in to our office and we rolled out Attendant Console to the new management team. One of the managers reported that the line status was not updating (the icons that indicated whether or not another user was on the phone), instead they were displaying question marks.

After a bit of troubleshooting, I discovered that the Attendant Console software registers the client’s IP address with the Call Manager server; I’m guessing that the server uses this IP address to send line status updates back to the client. You can view the IP address that Attendant Console has picked up by openning the Advanced tab in the Attendant Console Settings dialog; it displays the IP address and port where it says “Local Host IP Address (for line state)”.

When I checked the Local Host IP Address I discovered that it had picked up an APIPA address (169.254.x.x). I then did an ipconfig and saw that this machine also had a bluetooth adaptor with the address that was registered in Attendant Console. Fortunately, when I asked the manager about the bluetooth adaptor he said that he didn’t use it anymore so I just disabled it. Once I disabled the device and restarted Attendant Console I could see that it had registered the correct IP address and the line status was updating as normal.

I’ve had a look at the documentation but there doesn’t appear to be a way to force Attendant Console to use a specific adaptor. You can manually specify an IP address to use, but in most environments where DHCP is used this is not practical.

It’s been a little while since I’ve udpated my blog, mainly becuase I’ve been busy with work and studying. I passed the Exchange admin exam yesterday (70-284 - Implementing and Managing Microsoft Exchange Server 2003) and I’ve got a few days to breath before I start on my next exam: 70-293 - Planning and Maintaining a Microsoft Windows Server 2003 Network Infrastructure. As usual, I’ve created a Mind Manager map to create notes against:

70-293 Objectives Mind Map

Passing the 70-284 exam has given me the MCSA:Messaging status, and I have 2 more exams to take to complete the MCSE. Free time? What’s that?

Dealing with Member Servers

Re-deploying services

In some cases, rather than migrating a server from an NT4 domain, it made more sense to transfer the server’s function to another server or device. For example, DHCP was running on the PDC of one of the legacy domains to issue IP address leases to the workstations in their subnet. I opted to move the function to our switches. We are using 2 Cisco Catalyst 4507 switches; I worked with our network services team (the Cisco guys) to move the scopes from the NT4 server to the 2 switches. Each switch was given it’s own pool of IP addresses for redundancy and load-balancing.

Migrating Member Servers

There were several servers which needed to remain in use. For these servers the migration from their existing NT4 domain to the AD domain was as simple as removing them from the NT4 domain and adding them to the AD domain. The service accounts and ACLs on objects were already using groups from the AD domain (there were external trusts in place between the AD domain and the NT4 domains), and when I added the servers to AD users were still able to access resources on the servers. I tested this process in a lab before migrating the actual production servers.

Decommissioning the actual Domain

Removing the last Domain Controllers

I have completely decommissioned 1 domain so far, with the remaing 2 domains almost done. My aim was to remove all member servers until I was down to a PDC and a BDC. Once I got to that point, I disabled all of the user accounts except for the Administrator and REPL accounts. After a fews days, I then removed the trust relationships.

I took a backup of the PDC, but I wanted to have a very easy way to bring the domain back up if I needed to in future. I considered relying on a Ghost image, but that would require that the image be dumped back to the same hardware, and I knew that the hardware would be scrapped in the near future, leaving the image useless. Although I had the standard backup of the OS, I didn’t want to have to go through the whole restore process if for whatever reason I needed to bring a domain controller back up. My solution was to build an NT4 server in a Virtual PC image and promote it to a BDC in the legacy domain. Once I confirmed that the database had replicated, I shut down the domain controllers and burnt the Virtual PC image to DVD. If I need to bring the domain back up in future, it will be a simple case of starting the VPC session.