Tuesday, September 05, 2006

The Business of Blogs

Wow, considering the small spam attack we had here on Friday this article is timely reading.

When I started the EV Blog on Blogger I didn't know a whole lot about it, didn't know about the presence of blog spam, splogs, nothing. I just knew that I had heard about Blogspot before and it might be a good place to host a blog.

Now that I've been exposed directly, and now that my research shows how Blogger (and hence, Google) are part of the problem and not part of the answer... I'm toying with moving the blog over to Typepad. Here's my first draft.

It's got a couple of features that I like that Blogspot doesn't have, like the ability to have the "Read More..." links, categories, etc. Plus since it isn't a free service spam bloggers can't send bots out to open blogs for them. The signal-to-noise ratio should be pretty damn low over there.

So tell me what you think, either here or over there. I'll make this post on both sites and most likely will be posting over there henceforth.

Oh, and I promise real EV stuff coming on Wednesday! :)

Friday, September 01, 2006


Wow, two posts on a Friday. Well, I just had to moderate comments. If you want to know why check out the Friday Tech Tips for today, specifically the comments. Grrrr. Damn bottom feeders.

Late Friday Thoughts...

I don't normally post late on Fridays but this is something I wanted to comment on...

Mangle Those Cell Phones is an interesting blog entry by Richard Stiennon talking about other blog entries (notice how circular blogging has become? Wait, I'm doing it too!) where the basic gist is that a company released a study where they bought 10 used cell phones off eBay or someplace and WHOA, found personal info on those phones.

Why is no one looking at who this company is? (Note to self: Come up with a 'pulling my own hair out smilley") I know it's completely coincidental but *gasp* they happen to sell products to secure cell phones. Hello?

On a related note, today a group in Canada released a poll stating that Canadians overwhelmingly approved a blank-cd tax that goes to the artist and offsets piracy losses. The people who authored the poll? They're the one's who have a job collecting and disseminating that damn tax. Yeesh.

Tech Tip Friday: IndexCheck

Recent versions of EV have started shipping with utilities which is a great thing. Symantec believes (correctly) that the better we can support ourselves the better life is for everyone. The next few editions of TTF will concentrate on the currently shipping utils, and today we're going to start with the IndexCheck util.

IndexCheck: This util will perform a check on your indexes or index volumes. You can have it run a base check on the index or even crawl the entire index checking each word entry.

You will get massive warnings from the util about running it on live indexes. Heed these warnings and run it only on backup copies of the folders in question.

The basic command line parameters are listed in the docs so instead of regurgitating those here, I'll talk about each item.

-f     This param requires a path statement to the folder that you want to check. You will probably want to include an entire path statement, I'm not certain if virtual paths are accepted or not.

-c     This param states which tests you want to run. More on this in a minute.

-d     If you fire up dtrace in a separate command line and trace the IndexCheck service then include this command, your indexcheck will dump to dtrace along side whatever else you are dtracing. Useful if you think there's something wrong with the indexing engine. The dtrace output looks like this: link

-t     This sets the index tracing level. I always want to err on the side of too much data so I'll use this with '-t 6' to capture everything.

-ignorewarnings     Expert use only. Basically, it skips the 'Don't use this on live indexes' warnings at the start of the utilitie's run.

Now, the three tests you can run with the '-c' command. Here's some more detail and examples of each.

exists     This command merely runs through the index looking at basic things, a real quick once-over. Output from this check looks like this: link

words     This check will run through each and every word in the index, checking the entry. Output looks like this: link

docs     Checks each document in the index. Output will look like this: link


So, if you need to check the veracity of an index you could simply run through "indexcheck -f <path/folder> -t 6 indextrace.log" and let it assume the 'exist' check and dump everything to the "indextrace.log" file. This will run through the basic check, ensure that the files in the index folder are there and accurate.

If you still think there might be a problem you could run through all the docs that are in the index. That is going to be a little more thorough but take a little more time. "indexcheck -f <path/folder> -t 6 indextrace.log -c docs"

And then if you really want to ensure things are as ok as you possibly can, run this: "indexcheck -f <path/folder> -t 6 indextrace.log -c words" That will run through all the words in the index. Be warned that this will not be fast. A small index of only a couple megabytes of data took over 5 minutes to check 30,000+ words. The output linked above was snipped out of 250+M of trace log.

One more note: The documentation that ships mentions a parameter that checks if the avtrace.log file has any new entries. This flag is 'av <days>" and I couldn't get it to work. In fact if you go to a command line and enter indexcheck /? the online help makes no mention of this flag. I think it's another instance of incorrect documentation.

However, the logic still exists. If AltaVista has any issues it will dump trace info to the avtrace.log file. There's nothing really human-readable in there, but you are more interested in if there's ANYTHING in there at all. The file should be zero bytes long in a working index. Presence of any entries indicate possible issues, if the date on the entries coincides with errors in the app log then call support.

Wednesday, August 30, 2006


Got some interesting reading for you folks this afternoon. While it isn't EV-specific I think it might be of value to most of us.

Hacking DRM - I missed this last June but it's a good read about what is and isn't effect media-DRM. Very interesting.

Also, security consultant Ross Anderson just released the text of his acclaimed book "Security Engineering". Find the whole thing here.

And while we're talking about security check out this post on the Daily Irrelevant. Funny.

I've recently switched over to Firefox and found a sweet RSS reader called WizzRSS. It adds a tree-structure to the left of your browser. Come to a site like CNN or other news site and with a couple of button clicks you can add that site's RSS feed to the tree. Later in the day you can click on the entry in the tree and a small pane fills with that site's newsposts. Click on one and viola, the browser goes and fetches. Very intuitive and easy to use. It really makes daily news-reads (a must for any consultant) very easy.

Anyone else have any great plug-ins for FF?

Monday, August 28, 2006

A Little Coding Project

For the past who knows how long mail has been going into a journal mailbox. One person at the client site has been going into the mailbox every few days and dragging everything out to a local .pst. That .pst would get thrown into a fileshare along with the other hundreds or more that were already there.

Those all need to be inside EV. Of course.

This requirement kickstarted me to tackle a project I've been toying with for a while, a wizard that helps you write EVPM scripts. Because there's no way in hell I plan on hand writing the scripted PST migration for who knows how many PST files.

So I present PolicyDoc. Now one thing to keep in mind is that PD never touches your EV environment. Hell, you don't even need to install it in the same domain as EV. Simply feed it some report files, point it at the folder of PST's and let it generate the .ini file. You can then take that file wherever you want to and run it. Of course, please sanity check the file before running, practice safe hex and all that. Right?

But I need a couple of folks who wouldn't mind putting the code through the wringer for me. If you are interested I'll provide a compiled .exe file along with the full source code so you can roll your own if you want to.

Eventually I plan on releasing PD as open source, I just want to ensure that it's as clean as possible before letting go of it. Shoot me an email and let me know if you're interested.

Oh, and here's what she looks like so far...





Friday, August 25, 2006

Tech Tip Friday: Message Classes

From the customer's point of view the best way to determine if EV has archived a piece of mail or not is via it's icon. However, for engineers there is a better way, viewing the message's message class, which directly controls the icon being displayed.

The best way to see the message class in Outlook is to go to View | Arrange By | Custom. From the Field dialog box add in a column for Message Class. Once that's done you can see message classes for all items in Outlook. Any message that EV has handled will have the class of IPM.Note.EnterpriseVault.XYZ

So what else can you do with message classes? When EV archives an item the default behavior is change the original message to a safety copy until the .DVS files are backed up. Well a safety copy is identical to the original message with the exception of being a different class.

Ok, that's neat, what can you do with it?

Well, EV support gets calls from time to time where messages stay in Pending (safety copy) mode and won't transition to archived items. Sometimes those message also fail "Cancel Opertaion" and get stuck in Pending mode. If this is the case you definitely need to troubleshoot root cause, but it is possible to alter the message class back to IPM.Note or whatever it was originally. This will return the item to a fully functional piece of Exchange mail.

There are some third party products out there that will do this or it can be done programmatically if your good with Visual Studio. Symantec doesn't provide tools to do this, but I'm offering it as an option.

Until next Friday!

Monday, August 21, 2006

Secure Futures?

Hey, that's my old boss!

Apparently John Thompson, the CEO of Symantec was out at the Air Force Information Technology Conference recently and gave a keynote speech.

During the speach John was talking about securing the entire corporate environment, protecting IP assets across the spectrum and from attacks on multiple fronts and of course, he's right on all counts.

Now, while I don't think that John was specifically talking about Enterprise Vault, a large part of the EV endeavor is to secure the IP flowing through systems as much as anything else. Sure it's main goal is reducing clutter inside the Exchange stores or on the fileservers, but the product's close ties with AD and MSRMS servers bring to light another use for it: securing intellectual property.

By physically removing the files from their expected locations off to some other storage device you've added one more layer of abstraction that a potential intruder has to navigate to achieve access to those same files. Granted it's not on the same level a nice layer of 128-bit encryption, but every little bit helps.

Friday, August 18, 2006

Tech Tip Friday: Backups

Proper distaster recovery of your EV system requires some thorough backup plans. Most large IT shops have to support what's called the 'smoking hole' recovery plan which means you have to be able to recover if your server is, well, a smoking hole. Nice, but that'll never happen, right? Remind me to tell you the story sometime of a server room that was hit by the chinese mafia. Seriously.

Backup plans for EV have to contain at a minimum the following three items:

  1. Store locations
  2. All EV databases (directory and stores)
  3. Indexes

Additionally you can also backup MSMQ's, and Shopping Cart locations but those aren't strictly required.

One more trick that can be easy to miss is to make sure that all items are backed up at the same point in time. If you just backed up your databases and a user manages to archive something before you can get the stores done then you're facing possible dataloss in a DR scenario. Snapshot it all at the same time.

Tune in next Friday for another Tech Tip.