So what's a Tombstone Reanimation Feature?

They say that this feature is available in as early as Windows 2000 but this is the only time I am hearing about it. But what is it, anyway? Tombstore reanimation is the process of re-activating a deleted object from Active Directory. When Active Directory deletes an object, say a user or computer, from the directory, it does not physically remove the object from the database. Instead, it marks the object as deleted by setting the object's isDeleted attribute to TRUE, removing most of the attributes from the object, renaming the object, and then moving the object to a special container in the object's naming context (NC) named CN=Deleted Objects. The deleted object is now called a tombstone as is totally invisible from any LDAP tools like Active Directory Users and Computers. Even though the object is invisble, it is still there and readily available for us to salvage the data for the purpose of disaster recovery

This TechNet Magazine article highlights how to reanimate Active Directory tombstone objects in case you need to recover an object that has been accidentally deleted. I can't wait to try it out for myself though

Check the last backup date in SQL Server using WIndows PowerShell

This article highlights how to use Windows PowerShell to retrieve database properties using SMO. Notice how easy it is to check the database properties using pretty common syntax

One of the challenges I have when I was starting out as a SQL Server DBA was to check for the last backup date for a database. One way to do this is to find out which tables in the MSDB database contain the records of the backup history. What's really challenging here is the fact that you would have to look at the tables and their corresponding relationships which, apparently, MSDB doesn't have. You simply have to rely on what SQL Server Books Online has to say. Plus, the MSDB database will only contain records for databases with backups. What about those without?

For SQL Server 2005, the script below displays the last backup date of all the databases on your SQL Server instance. This script is from the MSDN Code Gallery

SELECT
T1.Name AS DatabaseName,
COALESCE(CONVERT(VARCHAR(12), MAX(T2.backup_finish_date), 101),'Not Yet Taken') AS LastBackUpTaken
FROM sys.sysdatabases T1 LEFT OUTER JOIN msdb.dbo.backupset T2
ON T2.database_name = T1.name
GROUP BY T1.Name
ORDER BY T1.Name

You can simply replace the sys.sysdatabases table with master.dbo.sysdatabases for SQL Server 2000

Below is the equivalent script using Windows PowerShell.

$instance="Your_SQL_Server_Instance_Name"
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO')| out-null

# Create an SMO connection to the instance
$s = new-object ('Microsoft.SqlServer.Management.Smo.Server') $instance

$dbs = $s.Databases
$dbs | select Name,LastBackupDate, LastLogBackupDate | format-table -autosize

The only thing to note here are the last two lines - the one that creates an instance of the database object and the one that displays and formats a few of the database object properties. The first few lines will be the same for just about any PowerShell script that will access SQL Server using SMO

Copying DTS packages from SQL Server 2000 to SQL Server 2005 and SQL Server 2008

I've seen this approach from the CSS SQL Server Engineers blog post and wondered if I can give it a shot. We're migrating a SQL Server 2000 database to a SQL Server 2005 instance (finally!) and that included a lot of DTS packages. While I would highly recommend upgrading the DTS packages to SSIS packages for the long term due to product support lifecycle reasons, that would take quite a while and would impact businesses dramatically.

I've used Method 2A mentioned in the blog post to move the DTS packages from the SQL Server 2000 to SQL Server 2005 as I have like more than a hundred DTS packages stored in MSDB. Remember that the size of the sysdtspackages table in MSDB will depend on not just the number of packages stored but the number of versions of the packages you decide to keep.

After a restore of the MSDB database from the SQL Server 2000 instance and importing the records from the sysdtspackages table, you would definitely want to install the Microsoft SQL Server 2000 DTS Designer Components to modify and edit your DTS packages in SQL Server 2005 to change those connection strings, test them after migration and so on.

No Drives Found error installing CentOS 5.2 on VMWare

Ok, so this is not my typical blog post that talks about anything Microsoft but it still is technology so it makes a good blog post.

I was installing CentOS 5.2 on a VMWare Workstation image when I suddenly hit a wall with this error

No Drives Found
An error has occurred - no valid devices were found on which to create new file systems. Please check your hardware for the cause of this problem.

Now, this isn't the first time I'm installing CentOS on a virtual machine nor on a physical hardware but it definitely is the first time to install version 5.2. Back in the old versions, everything was pretty straight-forward and that I had never encountered this error message before. I was beginning to be tempted to use an iSCSI disk for the installation with another virtualized iSCSI disk but I wouldn't want to go down that road unless I will be configuring this virtual machine as a clustered server. Having searched thru a ton of newsgroup and blog posts on similar issues, a few of them mentioned changing the Operating System to Red Hat Enterprise Linux or Other Linux 2.4.x kernel to make it work. I did find a recommendation to change the virtual disk from SCSI (which happens to be the default setting when you configure your virtual machine) to IDE. That did the trick, although I needed to create a new virtual machine in the process which was the quickest way to do it.

So, remember - use an IDE disk in your VMWare image when installing CentOS 5.2