The CMDB Entry Failed

OK, so I’ve been trying to add some Virtual IP Mappings on a FortiGate 200A running firmware v4.0,build0441,110318 (MR3)

Everytime I try to add a VIP via the web interface I get the following error

“The cmdb add entry failed”

The firewall still allows the rules to be added via the CLI but the web interface is a no go.

The solution for me was to reboot the FortiGate

ESXi Shell for the host has been enabled warning

So I have just spun up a new vSphere 5 install on my home lab.

One of the first things I wanted to do was fix the certificate error by replacing the default certificate with a one from my internal PKI.

The only way I can see to do this is via the shell. Shell access is disabled by default so the first thing to do was enable Shell access.

To enable shell access I went to the Configuration tab on the host and drilled down to Software – Security Profiles and enabled the ESXi Shell to Start and stop with host

I now have shell access enabled but I now also have a warning message on the host complaining about configuration issues and that ESXi Shell access has been enabled.

To disable the warning its simply a matter of going back to the Configuration tab on the host then – Software – Advanced Settings – uservars and changing the UserVars.SupressShellWarning to 1

Reseed failed DAG database copies

I have been working with a customer that has a large number of Exchange databases and wishing to to protect these with a DAG solution.

A multi node DAG had been built for the customer and one of the nodes was being problematic when it came to the initial seeding of the database.
The databases would initially seed fine, however as soon as they finished the DB’s momentarily reported “Healthy” before changing status to “FailedandSuspended”

I tried a number of fixes for this including manually copying log and catalog files, however nothing seemed to work. Then in true Microsoft fashion a reboot of the server resolved the issues and the databases seeded properly. After running an update against a DB it’s status remained “Healthy”

As previously stated the customer had a large number of DB’s that were being replicated so I resorted to the Shell to fix the remainder of the DB’s that were “FailedandSuspended”

The following command was used to bring the remainder of the DB’s back to a healthy state

Get-MailboxDatabaseCopyStatus –Server (MBXServerName) | Where-Object {$_.Status –eq “FailedandSuspended”} | Update-MailboxDatabaseCopy –DeleteExistingFiles –SourceServer (SourceMBXServerName)

Job done

Configuring Exchange 2010 Archive Mailboxes

I’ve been doing a large migration lately which has involved configuring all users with an Archive mailbox, setting the retention policy and moving items past retention into the Archive databases.

The users primary mailbox would reside on SAS disk while the archive databases were being stored on cheaper SATA disk.

The “Default Archive Policy”  of moving items older than 2 years into the Online Archive would be used

The high level steps for this were as follows.

1. Enable the users for archive
2. Setting the archive database and enabling the retention policy
3. Testing move of mail items past retention into the Archive database

As there were several thousand users on the system the only sensible way to achieve this was through the shell.

The users were already broken in 14 databases so naturally I approached this on a per database.

The following shell commands were used

Get-MailboxDatabase (DBName) | Get-Mailbox | Enable-Mailbox –Archive

Get-MailboxDatabase (DBName) | Get-Mailbox | Set-Mailbox –ArchiveDatabase (ArchiveDBName) –RetentionPolicy “Default Archive Policy”

Get-MailboxDatabase (DBName) | Get-Mailbox | Start-ManagedFolderAssistant

The Managed Folder Assistant runs nightly, however I used the above command to kick the process off immediately and verify that data was indeed moving to the new Archive DB

How to view Whitespace in Exchange 2010 Databases

With older versions of Exchange admins would use the 1221 EventID to see how much whitespace was available in each database.

With Exchange 2010 EventID 1221 is no longer used.

Admins now can query the database directly with the following PowerShell command to see the whitespace in each Database

Get-MailboxDatabase -Status | FT Name, AvailableNewMailboxSpace