Site Sections
Posts
254
Comments
120
Trackbacks
120
May 2005 Entries
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: 2.5.5.12; 
	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.

posted @ Tuesday, May 24, 2005 1:42 PM | Feedback (4)
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).
posted @ Thursday, May 05, 2005 4:52 PM | Feedback (0)
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!

posted @ Thursday, May 05, 2005 12:58 AM | Feedback (2)
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.

posted @ Wednesday, May 04, 2005 12:18 AM | Feedback (3)
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!

posted @ Tuesday, May 03, 2005 1:12 AM | Feedback (0)
News

Devin has moved on
to new adventures.
This blog is preserved
for historical purposes.

Please follow his
personal blog at:
Devin on Earth

Virtual Devin
Article Categories
Archives
Post Categories
Data Protection
DCAR
Exchange
Other
Security
Unified Communications
Windows