The Next Day; a beginning

[Editorial note: The Next Day is a working title for
now. I do not plan on publishing it on the Internet at this time,
beyond what is here. I will be starting to work again on
Silicon Cats and new chapters will be posted as they are completed.]

They were dancing again, keeping effortless pace with the music
only the two of them heard. The heavy drapes along the ballroom wall
let in just enough sunlight to show the footprints that quartered and
re-quartered the marble floor, tracks of last night’s spontaneous
celebration. Now that he no longer wore the skin of the Beast, I could
see how matched they looked, his handsome tanned face and orderly
length of straight black hair neatly pulled back by a simple metal
ornament complementing her flawless olive skin and curled blue-black
tresses. Her curls reached nearly to her waist; she had not spent any
time arranging an elaborate coiff and there was no magic to do it for
her this morning. The magic was gone as if it had never been, not a
single glittering trace of it to be seen anywhere in the dusty relic of
the estate house.

Yet I knew the magic was still present. It was not spread like
fog throughout the house and grounds as it had been for the long years,
giving me that instant awareness of all that happened. Instead it
curled tightly into a bright seed, tucked away within my chest. It
lurked there, a dragon in its lair, waiting for the right time to
emerge. I had never felt this before during my training and had no
trouble divining the meaning; it had gone, but it was not yet done with
us. The curse was lifted — Leandro stood proudly as a man among men
once again, no longer the fearsome monster — but the magic was only
biding its time. We three were still tied together, yet she only had
eyes for him. I realized then with dismay that I had been foolish
enough to fall in love with her.

This King kick and the power of words

Several months back, I bought the fifth novel (The Wolves of Calla)in Stephen King’s Dark Tower series for Steph. After we read it, we got the final two books from the library and read them. Since then, I’ve been on a bit of a Stephen King kick. I haven’t been reading everything he’s written, but I’ve been trying to read the ones that are in some way related to the Dark Tower series.

One of the ones that I picked up that isn’t related to the Dark Tower — and in fact isn’t much like his other novels at all — is Misery. This one is different because although he has some awful things in store for the protagonist, they are all purely human evils. There’s no supernatural source of the evil — just one very sick lady. No telepathy, no low men, no Breakers, no Beam, no ka, no haunted hotel rooms or telekinetic attacks or little girls who can turn an entire farm into a smoking inferno within a minute and a half. Just Annie Wilkes.

This book scared the tar out of me. Paul, the protagonist, is a successful writer who isn’t very content with his life or with the books that have made him a success. Up in Colorado Rockies, he is dumb enough to take on a snowstorm while drunk and pays a heavy price for his stupidity. You probably know the basics of the story (having either read the book or seen the movie) — he wakes up from a severe car accident, legs mangled and shattered, in the house of one Annie Wilkes. Annie declares herself to be his biggest fan who happened upon his car. He is in her guest room where she has been taking care of him, and his life is about to get seriously unhappy.

Annie is devoted to the main character of his best-selling series of books, Misery, and has not yet reached the finish of the lastest novel to find out that Paul has killed Misery off. Her reaction is the stuff of nightmares. No one knows where Paul is, his car is buried under feet of snow, and he is at her mercy. He slowly comes to understand that Annie is a killer, but she will not let him die until she has what she wants from him — a new Misery novel, bringing her favorite character back from the grave. Paul’s months with Annie break him in body, health, and spirit, even while strengthening him as a writer.

This book scares me more than any other I’ve ever read. Why? Because of my dreams of being a writer, specifically a novelist. I’ve wanted it ever since I was old enough to know that people wrote books. I’m acquiring the skills and discipline to make it happen, I think I have the gift, and I think I have the determination to get published and make my breakthrough. I have a head full of stories waiting to be told. All the pieces are in place; now I have to make them work.

I’ve got some freelance technical writing to do, but I’ve made an important decision tonight. I have to carve out time to do my personal writing or I will keep finding excuses not to do it. When I’m writing pieces for 3Sharp, I don’t have the luxury of waiting until I feel like it; I have to write to a deadline. Sometimes that means fighting an empty screen; sometimes it means staying up late to meet a commitment. Always, though, it means action, not intention. I will never be a novelist if I do not act to make myself one. It’s that simple.

Tonight, Steph and I — with the help of several friends from the PyraMOO — shattered one of my last excuses. I am now ready to write my first words for The Next Day, which will be a retelling of the story of Beauty and the Beast with a few hefty twists. I don’t know how it is for other writers, but I don’t want to have a detailed outline for a fiction piece. I want to have a general idea of how it’s going to go — who are the major characters, what do they want, where does the story start, where do I think it ends, and do I know any major stopping points along the way? Do I have any particular themes or symbols that help provide structure to the story?

Once I know these questions, the words come and the writing begins. The hardest part of this preparatory process, for me, is finding out about my characters. At first, I maybe know them only by the vague outline of the role they play in the story, by the shadows they cast on the insides of my eyelids. Slowly, I start to puzzle out a few details. At some point, I know enough about them to have a rough idea of who they are, but the critical step for nailing them down is to find their names. There are writers who can pick out a collection of personal details, grab a name out of a baby name book, and weave a character from whole cloth; they are bastards and I envy them, because I have to go sleuthing. I have to tease away each detail, each fact, and fit it into the puzzle until I see enough of the picture to accurately name what I am seeing. I now know the names of the four main characters; I know the flavor and feel of the world. Before I go to bed tonight, I will have the first paragraph of the story written.

I must have frustrated Steph. For me, the name is the central skeleton of the character, the structure from which all else hangs. Since my storytelling style is character-driven, I can’t tell you much about the world until I can tell you about the people. The characters drive everything else, and the names drive the characters. Once I know the name, I know how they think, what they want, what they fear. The name is my window into their mind. Steph doesn’t work like this; she’s not one of the kind of people for whom any old name will do, but I think she sees the name as just another detail one chooses for the character (perhaps off of a limited list; wouldn’t want to give the character an inappropriate name, after all).

For me, words are the boundary between chaos and order. Because of my Asperger’s, I am much more aware of the role that change plays in my life. I want structure, I want routine, and I have only a limited capacity for dealing with change. Yet I also recognize that entropy and change are constants and that perfect order is static and lifeless. Life depends on the interplay between chaos and order. Words, to me, are that interface — change and constancy brought against each other. With words, we take a small bite of chaos, a small bite of order, and we package them together into an imperfect symbol. They will never mean exactly the same thing to others as they do to us (hence the change), but they get enough of the meaning across to get the job done (the structure). Words are the building blocks of life in a very literal and mystical sense. In the beginning was the WORD, and the WORD was with God, and the WORD was God. God spoke Creation into being and gave to Adam and Eve the duty of naming all of the things He had created. Words are a gift, a charism, a power to be used in the pursuit of our relationships with the Divine, with His Creation, and with each other. Through our words we build and destroy, heal and hurt, grow and diminish. Words are not intentions; words are actions.

Active Directory fun: How to verify the presence of an attribute in your schema

Alerted by an old net.friend The Cerebrate via his blog, I was stunned to discover that the Windows Server 2003 flavor of the Active Directory schema seems to include an attribute named drink, which is meant to store a person or object’s favorite drink.

I confirmed that this attribute is at least present in the MSDN docs. But does it actually reside in Windows Server 2003? Which leads us to the main question — how does one go about finding out whether a given object or attribute exists in the AD schema?

So, I fired up LDP (although you can use ADSIEdit too, and probably should, since it’s very easy to use LDP to mess up AD — and whichever tool you use, make sure you’re not using an account with write access) and headed over to the schema naming context (CN=Schema,CN=Configuration,DC=domain,DC=rootdomain,DC=tld) for a quick look-see. Lo and behold:

Expanding base 'CN=drink,CN=Schema,CN=Configuration,DC=domain,DC=rootdomain,DC=tld'...
Result <0>: (null)
Matched DNs: 
Getting 1 entries:
>> Dn: CN=drink,CN=Schema,CN=Configuration,DC=domain,DC=rootdomain,DC=tld
	2> objectClass: top; attributeSchema; 
	1> cn: drink; 
	1> distinguishedName: CN=drink,CN=Schema,CN=Configuration,DC=domain,DC=rootdomain,DC=tld; 
	1> instanceType: 0x4 = ( IT_WRITE ); 
	1> whenCreated: 10/22/2002 18:50:14 Pacific Standard Time Pacific Daylight Time; 
	1> whenChanged: 08/07/2003 13:10:41 Pacific Standard Time Pacific Daylight Time; 
	1> uSNCreated: 4305; 
	1> attributeID: 0.9.2342.19200300.100.1.5; 
	1> attributeSyntax:; 
	1> isSingleValued: FALSE; 
	1> rangeLower: 1; 
	1> rangeUpper: 256; 
	1> uSNChanged: 4305; 
	1> showInAdvancedViewOnly: TRUE; 
	1> adminDisplayName: drink; 
	1> adminDescription: The drink (Favourite Drink) attribute type specifies the favorite drink of an object (or person).; 
	1> oMSyntax: 64; 
	1> searchFlags: 0; 
	1> lDAPDisplayName: drink; 
	1> name: drink; 
	1> objectGUID: db19f4f8-a922-429c-bd37-bd1e0a3dfd9c; 
	1> schemaIDGUID: 1a1aa5b5-262e-4df6-af04-2cf6b0d80048; 
	1> systemOnly: FALSE; 
	1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=domain,DC=rootdomain,DC=tld; 

So there you have it.

Update: Tony and I are now swapping ideas for AD-based drinking games:

  • Tony proposes writing a desktop agent that alerts you when your AD user object has been queried; when it has, take a drink. [Edit: that would require hooking into all your DCs, which would be a massive pain in the ass. I don’t think it’ll fly, but it’s fun!]
  • I proposed a game where you have to pick an object that has the drink attribute populated (without scanning the directory first); if they do, they take a drink and are the next person to choose, and if they don’t you get to take a drink and choose again.

What kind of AD drinking games can you come up with?

I wonder if our Cookbook editor Robbie knows about this. I’d be willing to bet he can come up with some great AD drinking games.

Cookbook progress

The Exchange Server Cookbook
(final title) is still on schedule for a June release. We finished the
final author hands-on review stage a week or two back and got to see
our cover this week. (Yes, it’s a baboon; our editor Robbie told us that this was what the art department came up with from his description of the three of us, to which Paul manfully replied that I’m too bald and Missy is too good looking, so it must have been him.)

Those of you reading this from my site can see that I’ve added a
link to Amazon for the book (if you’re reading on the LJ feed or via
RSS, please come to the site and take a quick look). If this is a book
you think you’d like, consider ordering it from the link on my site;
you get the standard Amazon experience while I might get a small
kickback. (John Scalzi’s recent post about the economics of writing,
combined with my observations about the effect of my growing writing
self-employment income on my tax situation, made me do some thinking.

This is an experiment. Like a lot of bloggers, I’m going to make
judicious use of my shiny new Amazon associate status and see how it
works out. It cost me nothing and I see nothing morally or ethically
objectionable in promoting a book I helped write, so I have nothing to
lose. Since 3Sharp was kind
enough to take the contract for the book in its name, we got the
benefit of getting paid our regular salary to write the book instead of
receiving the advance and then having to factor it out into all the
hours we spent on the book. What this also means is that Paul, Missy,
and I (as the three authors initially assigned to the project; Tom
Meunier was in the trenches with us for a good part of it) got to give
up a lot of nights and weekends without even the dubious distinction of
the miniscule per-word rate we would have received the other way, after
all the work was done. (I’ve learned that you don’t go into writing
technical books to get rich. For the comparitive effort involved, the
money in magazine articles is astoundingly higher.)

Don’t get the wrong idea; I jumped at the chance to do this book and
would have no matter how they offered the terms. It was a valuable
learning experience in itself, as well as giving me a much-needed dose
of confidence and look into some of the darker corners of Exchange.
More importantly, I now have a baseline — and I know that I want to
keep writing. Good thing, too; I’ve got a few freelance projects coming
up that will be fun and profitable. More on those later.

Ecubed, Day 4: More Exchange SMTP virtual server myths

During today’s session, Konstantin directed our attention to SMTP Virtual Server Myths Exposed a particularly useful and classic post from the Exchange product team blog, You Had Me At EHLO (you are reading that , right?). We used that post as a launching point for a good discussion about having multiple SMTP virtual servers on Exchange. Since I hear a lot of misunderstanding about some of the points we raised during the discussion, I wanted to add a couple of new myths that were distilled down from today’s session.

Additional Myth #1: Virtual Servers are bound to a specific IP address
This is only partly true, and not in the way many people think. A virtual server must be able to bind to a unique IP address/TCP port combination so that it can listen for incoming connections. That’s the only reason you need each VS to have a unique combination: you can only have one process bind to a particular combination of IP address and TCP port. By default, SMTP uses port 25 and changing that will get you in a world of hurt except in certain specific situations, so in practice this means that each VS must have its own unique IP address. Again, that’s just for accepting inbound connections; Exchange will, like any other application on a multi-homed machine, select the most appropriate source IP address based on the Windows routing table when it initiates an outbound connection. This helps explain why the answers to original myths 1 and 2 are the way they are; they assume that you understand the underlying routing structure.
Additional Myth #2: You need to enable packet forwarding if you have multiple Virtual Servers on the same machine
I cannot stress strongly enough how false this is. Never, never, never enable packet forwarding unless your machine requires it (and if you’re using software like ISA or RRAS, they’ll enable it for you). You’re doing application-level routing of SMTP messages, not IP routing. This also amplifies original myth 1; any connection restrictions you apply will apply to other VS instances, so make sure you’re allowing connections from the proper IP addresses (depending on your routing scenario).

Ecubed, Day 3: A neat SMTP connection restriction trick

For the rest of the week, I’m in the Securing Microsoft Exchange Server 2003: Defense in Depth class taught by Microsoft’s Konstantin Ryvkin. Konstantin is another extremely knowledgeable member of the Microsoft IT team and is again giving us a unique and valuable look into the principles he is teaching by showing us how Microsoft has implemented them in their production Exchange environment.

For all of the power that Exchange 2003 brings to the table, there are always limitations that can make life really annoying. One such limitation is found when you try to restrict incoming connections to an SMTP virtual server. Exchange gives you two methods for such restrictions: source IP address or SMTP authentication. A common scenario is that you have a set of hosts you wish to be able to connect to your SMTP VS anonymously (such as from trusted business partners) but require authentication before allowing mail submission from anyone else (allowing your roaming users to use your server when outside the network). Out of the box, you can’t do this with a single SMTP VS. If you enable both restriction types, Exchange uses a logical AND to evaluate them The results: only authenticated users from the trusted hosts can connect.

The workaround involves a lot of pain and usually requires a second virtual server or machine. Both of these scenarios can cause their own problems and complications; quoting from Chapter 6 of the Exchange Server 2003 Routing and Transport Guide:

If you use multiple SMTP virtual servers on a single Exchange server, be careful when you configure them. By default, multiple virtual servers cannot communicate with one another. For proper mail flow, you need to configure them appropriately so that mail can be routed between them. Additionally, each SMTP virtual server must be configured with a unique Internet Protocol (IP) address and port combination. Generally, all SMTP virtual servers require port 25 so you must assign unique IP addresses to them.

Thanks to Konstantin, I learned that there is a little-known IIS 6.0 metabase parameter that can be quite useful for this situation (yet another reason to deploy Exchange 2003 on Windows 2003). The SMTPIPRestrictionFlag property (PropID 37031) controls the logic that Exchange uses. In the default setting of 0, Exchange uses the logical AND, resulting in the out-of-the-box behavior. You can set this to an alternate value (I’m guessing 1, but I don’t know for sure because the only documentation for the property is rather sparse) to trigger the use of the logical OR. The end result? Exchange will allow anonymous connections from trusted IP addresses and authenticated connection from any address. Exactly what we wanted!

I’m sure I’ll have spare time in the lab tomorrow, so I’ll ask for more details and trying playing with it to cobble together a usable example for you. Stay tuned.

Update 0920 PDT 05 May 2005: Konstantin has confirmed that you want to set SMTPIPRestrictionFlag to a value of 1 in order to enable the logcial-OR behavior. Even though this property has been minimally documented for a while, it’s only been last week that they’ve been allowed to start talking about use of this property. Breaking news from Ecubed!

Yo Missy!

Um, Missy dear, what exactly have you been telling the fine Exchange ladies and gentlemen about me? I’m taking an incredible ration of shit from the assorted suspects and they keep mentioning your name. And Tom, your name has gotten taken in vain more than once.

And for the record, my kilt shows off what a stud I am. Disagree all you want, but a certain luscious redhead says so and she trumps.

That is all.

Ecubed, Day 2: Getting more out of NTBackup; Jetstress UI

It’s pronounced ee-cubed, not ek-yoo-bed. You know, E to the third power.

Dave gave us a thorough description of the past, current, and proposed plans for the production Exchange deployment at Microsoft. I wasn’t at all surprised to find out that Microsoft is using disk-to-disk backup for their Exchange databases, but I was more than a little surprised to find out what they’re using: good old NTBackup. NTbackup performs a streaming backup to a separate set of disk resources in the cluster. Once the backup is done, the disk resources are dismounted and remounted to one of the passive servers in the cluster. From there, the dump files are backed up to tape.

One of the problems they ran into was a throughput limit with NTBackup: 640MB per minute. This is a definite problem when you have a four-hour backup window and terabytes of data to dump to disk. The four-hour window is pretty strict in order to avoid overlapping with online maintenance and the morning user traffic. They reduced the data size by using separate backup jobs to backup each individual mailbox store database, rather than each storage group as a whole, but it wasn’t enough.

As it turns out, there are some undocumented registry parameters that affect NTBackup’s performance:

  • HKCU\Software\Microsoft\Ntbackup\Backup Engine\Logical Disk Buffer Size — the default value is 32; Microsoft changed it to 64.
  • HKCU\Software\Microsoft\Ntbackup\Backup Engine\Max Buffer Size — the default value is 512; Microsoft changed it to 1024.
  • HKCU\Software\Microsoft\Ntbackup\Backup Engine\Max Num Tape Buffers — the default value is 9; Microsoft changed it to 16.

With these changes they were able to get ~1.2GB per minute, enough to meet the window. They arrived at these values through testing, so make sure you test in your environment to find out the best values for your configuration.

There are advantages to backing up the individual databases rather than the storage group. The main benefit is that it creates a set of smaller files that can be moved to tape from the passive server with multiple streaming jobs, making better use of the tape device pool and allowing a higher number of concurrent backup streams. Depending on the media used, you can eliminate spanning multiple media.

I’d somehow managed to miss this detail in the article on the Microsoft IT Showcase website, but it is there, along with a wealth of other detail. Give it a look if you haven’t already.

The other tidbit for the night is to check out the new version of Jetstress. The most obvious difference is that it’s now a GUI utility rather than the command-line utility we’ve all come to know and love. There’s also been a change in the recommendations for using Jetstress. Previously, Microsoft recommended that you use a test database one-twentieth to one-tenth of the size of your expected production database size. It turns out that this recommendation is likely to cause a condition known as short-stroking, which is when the disk head only moves over a small portion of the platter instead of the full distance. Short-stroking artificially reduces the head seek time which elevates your disk throughput benchmarks far past levels that you can sustain under production circumstances with fully populated databases.

Instead, you should use something much more representative of your final database size — at least 70%, preferably 100% if you have the capacity in your test lab. As always, the best test scenario is as close to production as you can get.

Ecubed, Day 1: A word about write caching and Exchange databases

I’m spending this week at the Exchange Emergent Evolution (Ecubed) conference in downtown Seattle. It’s a small, intimate gathering for technically minded Exchange professionals to get together and get the latest and greatest advanced training. The big downer is that there’s no wireless connectivity, so I can’t blog from the conference. On the other hand, the office can’t e-mail me, so I think I’ll live.

For Monday and Tuesday, I am in the Storage Best Practices session taught by Microsoft’s Dave Lalor; for the rest of the week, I’ll be in the Defense in Depth: Exchange Security session. The first day of the storage session has been an absolute blast and joy; Dave really knows his subject, communicates his excitement and knowledge very well, and has access to the live performance data from the production Exchange servers at Microsoft to illustrate his lessons. It’s awfully hard to argue with someone who is walking through some incredible graphs of high-load production Exchange 2003 SP1 servers purring along like kittens.

Some tasty tidbits from day one (if I go by too quickly, don’t worry; I plan to write these up in more detail later):

  • Remember the old advice to always disable write caching on your controllers? This advice comes from the days when clusters used shared SCSI disk systems; each host had its own indepedent SCSI controller on a shared SCSI bus. If a host failed, any data in the cache that hadn’t been committed to disk was lost, creating a hole in your Exchange databases that would nuke them from orbit. If you’re the last person still using this “ghetto clustering” (as one of my fellow conference goers dubbed it), keep following this advice. If you’re using a modern SAN solution, enable your write caching and enable it now. The cache is not on the host, but on the controllers in the array, and the better arrays with redundant controllers make sure cache information is shared between all controllers (verify that yours does this, of course!) The resulting performance win will make your Exchange servers much happier.
  • If you have a dedicated array for your Exchange boxes, don’t bother with read caching on the array. Exchange does not benefit at all from read caching.
  • Contrary to popular opinion, RAID 5 volumes may in fact be suitable for your Exchange database mounts depending on the particlar I/O characteristics of your traffic. A big part of this is how your RAID controller handles write caching. Any type of RAID array introduces additional I/O operations (IOPs) behind the controller; a RAID 10 array (a stripe of mirrored disk pairs) turns every one write IOP at the host into two write IOPs at the controller. RAID 5 arrays can incur an additional penalty; this varies by vendor and model. A common penalty factor is 4: each write IOP at the host incurs an additional two read IOPs and two write IOPs at the controller. With detailed knowledge of your disk performance, your database design, the particular of your RAID controller, and some careful attention to detail, you can produce more than acceptable performance for Exchange databases on a RAID 5 volume.

More later!

Good-bye Vacation, helloooo iPod!

Why do I continue to set seemingly unreachable goals for my off-time? You’d think that three days of vacation followed by two days of weekend would be enough time to get a bunch of stuff done, right?

Rhetorical questions aside, while the vacation was good, it will be nice to get back to work. All this week, I’ll be heading into the Grand Hyatt in Seattle for a five-day Exchange conference. Steph will effectively have the house to herself during the days, which is going to be some much-needed separation for the two of us. That’s the downside of working from home — if she’s home a lot, we’re in each other’s hair all day long and that not good for either of us. Besides, this will be my first conference in which I’m not presenting, proctoring, or somehow tied to the creation of content, and it will be a welcome change of pace (not to mention chock-full of great advanced Exchange content and a great place to meet up with some more of my peers in the industry) to sip from the firehose of ongoing education.

At least I’ll have one of the major downsides of the commute to Seattle beat this time, thanks to my new 40GB iPod. Although it’s not shiny new (I bought it from a friend who upgraded), it’s my first iPod and provides proof that I’m moving farther along the path of the Apple cult. Much angsting of peripherals later, I settled on combination case/flat panel speaker that allows me to use it in the car (albeit not with the car’s stereo — those are $40 and more) and in my office.