a Flo + a Blog = a Flog

Today I ran into an interesting error when trying to access one of my VM.

First I could not get into that VM remotely as it appeared as offline. This said, VI showed the VM as healthy and online.

Trying to get to it using the Console from VI showed the following error:

As you can see I was afraid that some of the SAN path were down or some kind of painful problem with the SAN. No, no a quick ssh in showed that the mentioned volumes were online, accessible and all SAN paths were up.

So I do power off and restart the VM: no success. Restart the ESX (after vmotioning all VMs): no success.

Eventually I find that in the settings of the VM, there was  a reference of some floppy image pointing to a volume (not even on the same volume). I changed that option to Client Device and voila everything was back to normal.

Looking that information up on the VMware KB or community forum  doesn’t provide any solution.

I only played with ESX4 regular flavor so far and I wanted to try mixing them with ESX4i. However trying to put that host in my cluster would give me HA error.

Enabling HA gave the error:
“Cannot complete the configuration of HA agent on the host. See the task for details for addional information. ”

Without much details I was almost ready to blame it on ESX4i. However after checking everything I found out that my DNS servers settings were wrong.

Changing my DNS to the right IPs and HA configuration worked like a charm.

Obviously my sticky keys did not help but of course stressed out the reminder that HA relies on DNS heavily.

If you live in T.O. and use the TTC quite often you probably noticed that from time to time there are some public announcement made to TTC employee. I have always wondered what would mean 299 bloor call control or other like this.

In an attempt to understand, I was able to find the signification for one of them. I hope I find more.

“299″ Line Mechanic call. There are “Line Mechanic’s” posted at Kipling, Keele, St.George, Bloor, Chester, Kennedy, Eglinton, St.Clair West & Sheppard.
“101 – 120″  Supervisors
“122″  Subway Line Supervisor
“199″ Subway Line Mechanic Supervisor
“143″ Chief Supervisor
“147″  Fare Supervisor
“148″ Transit Patrol Security
“201 – 220″ TTC Armored Trucks
“301-310″  Streetcar Track/Overhead Maintenance
“506″ Station Janitor

Today I ran into a situation where someone accidentally deleted an account by mistake. It is pretty easy to solve something like that when you have the right tools.

For this recipe, you will need:

• adrestore, a great tool from our friend Mark
• Admin rights on AD, to perform what you have to do

For your sake, AD keeps deleted record for 30 days by default. If it was an important account, there are great chances you notice it is missing before the 30 days. Past those 30 days, you will need to use the “standard authoritative” AD backup method.

Your application using the deleted account will complain and a query on AD reveals it is not there. Not a problem, just follow the 4 easy steps below:

1. Restore the missing account
adrestore.exe -r MissingAccount
Enumerating domain deleted objects:
cn: MissingAccount
DEL:eab4d5e6-493b-4a64-aae8-360e730a5938
distinguishedName: CN=MissingAccount\0ADEL:eab4d5e6-493b-4a64-aae8-360e730a5938,CN=Deleted Objects,DC=rgare,DC=net
lastKnownParent: OU=Service Accounts,OU=Users,OU=Montreal (MTL),DC=COMPANY,DC=net

Do you want to restore this object (y/n)? y

Restore succeeded.

Found 1 item matching search criteria.

2. Query to check its existence
dsquery user -name MissingAccount
“CN=MissingAccount,OU=Service Accounts,OU=Users,OU=Montreal (MTL),DC=COMPANY,DC=net”

3. Reset Password as restored account comes back empty
net user /domain MissingAccount Password

4. Activate Account
dsquery user -name MissingAccount| dsmod user -disabled no
dsmod succeeded:CN=MissingAccount,OU=Service Accounts,OU=Users,OU=Montreal (MTL),DC=COMPANY,DC=net

At this point and under 3 minutes, the deleted account is restored and ready to be used. It even kept its SID but you will have to repopulate some of its attributes such as Description and so on.

As I am designing and implementing the Enterprise Content Management (ECM) for my company, as I am presenting concepts and initiating changes to the company electronic content management a lot of people are confused about the difference between Document Management (DM) and Record Management (RM).

I think it is easier to understand if you look back in the past and see how those were used.

RM systems were first developed to manage paper files. They could also manage other physical records, such as microfilm and photographs. RM systems help you perform the
following tasks:
• Opening, closing and registering files, folders, dockets, and individual documents.
• Tracking the location of files.
• Charging files out to users.
• Classifying records.
• Indexing records.
• Searching for records using keywords and other search criteria.
• Managing the active and semi-active retention of the records.
• Managing the disposal of records.
• Managing access to and security of records.
Newer versions of RM systems can capture and manage finished electronic records.
They streamline many of the most time-consuming records management tasks. Using an RM system makes it easier to search for records, transfer them to the records centre, and dispose of them.

RM systems were created to make it easier to manage paper records. In contrast, DM systems were created to make it easier to use electronic records. DM systems are designed to keep track of changes to electronic records, share them, and route them to different people.
DM systems integrate with most software packages that you use to create electronic records.
Typically, when you try to send an e-mail message or save an electronic record, the DM system will prompt you to fill out a profile form. The electronic record is saved into the DM system and stored on a DM server. You must go through the DM system to retrieve the record.
DM systems have several strengths, including:
• Capturing electronic records at the point of creation.
• Full text searching of documents.
• Tracking of different versions of the same document.
• Monitoring who has viewed a document.
• Capturing document images from a scanner.
• Passing documents along a workflow. This is useful where a document must be passed
through several people for editing, response, review, or approval.
Early DM systems did not manage records. They had limited ability to classify records and they could not apply retention and disposition schedules.

To Sum Everything Up
Records Management:
• Management of the record is more important than the content of the record
• The record never changes (although its properties might)
• Records require access controls, lots of them

Document Management/Collaboration:
• Without content there is no document
• The document changes a lot, that’s the whole point of collaboration
• Access controls restrict and impede collaboration, the fewer there are the better