sheenaustin.com » Windows Server

Symantec Backup Exec Error 0xe00084af (All Versions)

Sheen — Fri, 11 Jun 2010 11:35:43 +0000

I have been tearing my hair out for a couple of weeks with this error and Symantec wasn’t of any help. We had this error with version 12.5 of Symantec Backup Exec and it started on a server apparently out of the blue after having no issues for over 2 years.

Out of ideas and with no help from Symantec, we upgraded to version 2010 hoping that this would fix the error. No go. The backups still failed. We were back to square one.

I knew that it was something that had gone wonky with VSS that was throwing things in disarray. I ended up going back to the good old trial and error method to fix this issue. I first tried killing the vsssvc.exe process before the backup started – didn’t really fix the issue. I tried one thing after the other with VSS but it all failed.

Then one day, I tried stopping the SQL VSS Writer – I dont know why I did it but I guess it was a hatred deep down I now had for VSS that made me stop that service but Halleluijah! it fixed the issue. I know this wont make any sense – it still hasn’t made sense to me – I don’t know why an SQL VSS Writer would mess up a file system backup, but lo and behold the problem was history.

If you have lost hair and time working on this issue, go ahead and add ‘net stop SQLWriter’ to the pre-command and ‘net start SQLWriter’ to the post command and you will not have these issues anymore.

Drop me a line if you think this post helped you.

OCS 2007 Protocol Stack Error Event ID 14517 When Starting Services

Sheen — Fri, 15 Jan 2010 21:03:11 +0000

You may come across this error message when you install Office Communications Server 2007 for the first time in your environment. This error generally is seen after you run through the initial steps and are trying to start the OCS services for the first time.

This event ID will contain the following message:

ERRORS:
Two server roles at FQDN [server.domain.com] have different ‘Treat As Authenticated’ options. First server has GUID {58BDE507-1C48-4BA4-BCDF-06FB59ADF9CE} and role ‘Enterprise Edition’ (option is set). Second server has GUID {BD77F03B-4451-4171-A035-FC7FB264383D} and role ‘A/V Authentication Service’ (option is not set). Two server roles at FQDN [server.domain.com] have different server version numbers. First server has GUID {58BDE507-1C48-4BA4-BCDF-06FB59ADF9CE} and role ‘Enterprise Edition’ (version 3). Second server has GUID {BD77F03B-4451-4171-A035-FC7FB264383D} and role ‘A/V Authentication Service’ (version 0). Two server roles at FQDN [server.domain.com] have different ‘Treat As Authenticated’ options. First server has GUID {58BDE507-1C48-4BA4-BCDF-06FB59ADF9CE} and role ‘Enterprise Edition’ (option is set). Second server has GUID {1719A023-DDB4-5170-836D-3299D4F067C6} and role ‘Edge Server’ (option is not set). Two server roles at FQDN [server.domain.com] have different server version numbers. First server has GUID {58BDE507-1C48-4BA4-BCDF-06FB59ADF9CE} and role ‘Enterprise Edition’ (version 3). Second server has GUID {1719A023-DDB4-5170-836D-3299D4F067C6} and role ‘Edge Server’ (version 0).

WARNINGS:
No warnings

Cause: The configuration is invalid and the server might not behave as expected.
Resolution:
Review and correct the errors listed above, then restart the service. You also wish to review any warnings present.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This error can be misleading. The primary reason you see this error is simple – You have had a previous installation of OCS in the domain and there are still a few entries in Active Directory that haven’t been cleaned up even though you did a clean uninstall of OCS.

This is what you need to do to fix the error:

Please Remember – You are following the instructions below at your own risk.

Open up adsiedit.msc and browse to the system configuration partition under Domain –> DC=domain,DC=com –> System –> Microsoft –> RTC Service.

NOTE: This is safe to perform only if you do not have a current working installation of OCS in your domain or forest.

Select and delete everything under this key.

Now go ahead and run the setup again (you will have to run the forest prep again) and you will be all set!

How to Backup and Restore Active Directory

Sheen — Thu, 08 Oct 2009 00:53:00 +0000

There are many documents written about backing up Active Directory but I didn’t find enough documentation that would help us restore Active Directory. So here is a guide aimed to provide insights into correctly backing up and restoring Active Directory.

Here is my mini how to – I have tried to keep it as simple as possible:

Backing Up Active Directory

Active Directory depends on the system state and the NTDS database among other things. So it is important to back these up on your domain controller. It is critically important to ensure that the system state data on a domain controller is backed up regularly since this contains all the core system files that are required to run a domain controller. Manually selecting what needs to be backed up will be extremely complicated and could be error prone – stay away from that path – just backup the entire system state.

What needs to be backed up? – System State

What kind of Backup needs to be run? – Full backup of the system state.

How often is good enough? – Daily – You will thank me for this

Restoring Active Directory (for experts who just need the short version)

There are two types of restores:

1. Normal Restore – This was also called the Non-Authoritative restore. This is generally performed when you need to restore a domain controller that has failed and there are other domain controllers on the domain. Another option would be to just reinstall the domain controller, clean up the AD metadata of all references to the failed DC and then promote the new server to a DC and replicate. If you are in a situation where you cannot do that, to perform a normal (or Non-Authoritative restore) you would:

a. Boot the domain controller into the Domain Services Restore Mode .

b. Restore system state

c. Reboot into the normal mode.

d. Replicate from other domain controllers.

2. Authoritative Restore – This would be performed in cases where you make a mistake like, say, delete an OU. In this case, a normal restore would not help since the OU that you just restored would get deleted again when you replicate changes with other domain controllers. An authoritative restore would help you undo a big mistake by ensuring that you are taken back to a working copy of AD. However, changes that you made since the last full backup would be lost. (So run your full backups daily!). To perform an authoritative restore:

a. Perform a normal restore.

b. Don’t reboot after the restore.

c. Use ntdsutil to get into the authoritative restore mode.

d. Specify if you want to mark the entire database or just a subtree as authoritative.

e. Quit the utility and reboot the server

3. Primary Restore – This restore is only used when you have a major disaster (read complete meltdown) and you have no working domain controllers. In such a case, you will have restore the entire domain from backups. The working process is very similar to the Normal Restore procedure mentioned above. This is how you would do it:

a. Boot the domain controller into the Domain Services Restore Mode .

b. Restore system state – ensure that the advanced option ‘Mark the restored data as the primary data for all replicas’ is checked.

c. Reboot into the normal mode.

Restoring Active Directory (for the rest of us)

1. Normal Restore – Here’s the step by step.

a. Reboot Server

b. During startup press F8 and choose, ‘Directory Services Restore Mode (Windows DCs only)

c. Choose the OS to be started, hit enter.

d. Hit OK at the Safe Mode login.

e. Open up the NTBackup utility.

f. Click next on the welcome page.

g. Select ‘Restore Files and Settings’ from the backup or restore page. Click Next.

h. Choose the backup you want to restore from the ‘What to restore’ page. Click Next.

i. Click Finish to start the restore. (Advanced options are best left untouched for a normal restore unless you want to save the backup elsewhere.)

j. Reboot server.

2. Authoritative Restore –

a. Perform a normal restore as mentioned before.

b. Do not reboot server after the restore.

c. Click on start -> run -> type ntdsutil.

d. Now type ‘authoritative restore’

e. Now specify the components you want to make authoritative. Enter either ‘restore database’ or ‘restore subtree’ along with the DN of the AD object you want to make authoritative.

f. Confirm your actions when prompted.

g. Type quit until the utility exits.

h. Reboot server.

3. Primary Restore –

a. Reboot Server

b. During startup press F8 and choose, ‘Directory Services Restore Mode (Windows DCs only)

c. Choose the OS to be started, hit enter.

d. Hit OK at the Safe Mode login.

e. Open up the NTBackup utility.

f. Click next on the welcome page.

g. Select ‘Restore Files and Settings’ from the backup or restore page. Click Next.

h. Choose the backup you want to restore from the ‘What to restore’ page. Click Next.

i. Click Advanced.

j. Ensure that on the ‘Where to Restore’ page, the default setting ‘Original Location’ is selected. Click Next.

k. On the How to Restore page, ensure that ‘Replace existing files’ is selected. Click Next.

l. On the Advanced Restore Options page – enable the ‘When restoring replicated data sets, mark the restored data as the primary data for all replicas’ option. Click Next.

m. Click Finish to start the primary restore.

n. Reboot server.

o. Go to sleep

PS: As always, please exercise due diligence when using the instructions in a live environment. Kindly do not blame me if something doesn’t work if Microsoft decides to change their code.

Dude, where’s my mailbox stats?

Sheen — Mon, 20 Jul 2009 07:49:00 +0000

One of the most frequently used Exchange 2003 mailbox management administrative features was the mailbox size, total item count, last logon time, log off time etc. For some strange reason, this convenient feature has been left out of Exchange Server 2007. If you are reading this blog then you probably are looking for a way to get these stats back.

The Exchange 2007 power shell is power packed to deal with this drawback and you can get all the info you need (displayed just like ESM 2003) in a jiffy by running this command (you will need to substitute MailboxServer01 with your server name):

Get-MailboxStatistics -Server MailboxServer01 | Sort -Property TotalItemsize | Format-Table DisplayName, LastLoggedOnUserAccount, ItemCount, @{expression={$_.totalitemsize.value.ToMB()};label=”Size(MB)”}, LastLogonTime, LastLogoffTime | Export-CSV ExMBXInfo.csv

All this info would get written to a csv file with the filename ExMBXInfo.csv (Edit the file name in the command if you want to call it something else)

The variables used here are DisplayName, LastLoggedOnUserAccount, ItemCount, TotalItemSize, LastLogonTime, LastLogoffTime. There are a host of other variables that can be used to get more information. Here are some of these variables that can be used:

AssociatedItemCount
Database
DatabaseName
DeletedItemCount
DisconnectDate
DisplayName
Identity
ItemCount
LastLoggedOnUserAccount
LastLogoffTime
LastLogonTime
LegacyDN
MailboxGuid
ServerName
StorageGroupName
StorageLimitStatus
TotalDeletedItemSize
TotalItemSize

Drop me a line if this article helped you!

The WinRoute tool

Sheen — Sat, 18 Jul 2009 07:56:00 +0000

WinRoute.exe is a tool that can be used to view and easily understand a complicated Exchange email routing topology. This tool is a recommended first step towards troubleshooting Exchange Email routing issues.

To install the tool, go through the following checklist:

Ensure that the ‘Routing Engine Service’ is running.
Ensure that the MTA Stacks Service is running.
Ensure that the SMTP service is running.
Ensure that the Program Files\Exchsrvr\Bin\ directory has the following files
1. Dsaccess.dll
2. Pttrace.dll
3. Exchmem.dll
Download the WinRoute tool from here.
Copy winroute.exe to the Program Files\Exchsrvr\Bin directory.

To use WinRoute:

Execute the winroute.exe file.
Identify the routing group ‘master’ server.
Connect to the master server (This is always recommended)

WinRoute works on all Exchange 2000 and 2003 servers and uses the Link State Protocol (TCP 691) to get routing information. Exchange 2007 does not have a routing engine so this tool will not work on Exchange 2007. However, there is a similar tool called the Routing Log Viewer in Exchange 2007 that provides similar functionality.

Give this a whirl and drop me a line if you found this useful.

Remember! it is always good to share!