Address generation question
asti...@my-deja.com
I am running Exchange 2000 on Windows 2000. I want to add a new SMTP
address to all users of the form <firstname>.<lastname>@company.com,
but cannot see a way to do this.
Any ideas?
Thanks,
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
![Ed Crowley [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjU58iIPW1gnybcssBVjGlULqRvfqqIfd2fnY82PjMQkTlwpNg=s40-c)
Ed Crowley [MVP]
Directory import.
--
Ed Crowley MCSE+Internet MVP-Exchange
Tech Consultant
Compaq Corporation
Protecting the world from PSTs and Bricked Backups!
Exchange FAQ: http://www.swinc.com/resource/exch_faq.htm
<asti...@my-deja.com> wrote in message news:8rfd9j$t5v$1...@nnrp1.deja.com...
Rich Matheisen [MVP]
asti...@my-deja.com wrote:
>I am running Exchange 2000 on Windows 2000. I want to add a new SMTP
>address to all users of the form <firstname>.<lastname>@company.com,
>but cannot see a way to do this.
See the "recipient policies" in ESM.
------------------
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
asti...@my-deja.com
Rich - I found this, but couldn't determine how to influence the part
of the address before the @ symbol. Any hints?
asti...@my-deja.com
addresses into the export file and re-import. That correct? What about
new users in the future?
Thanks,
Andrew
In article <uD30uUjLAHA.278@cppssbbsa05>,
"Ed Crowley [MVP]" <ej...@clownpenis.fart.pacbell.net> wrote:
>
> Directory import.
> --
> Ed Crowley MCSE+Internet MVP-Exchange
> Tech Consultant
> Compaq Corporation
> Protecting the world from PSTs and Bricked Backups!
> Exchange FAQ: http://www.swinc.com/resource/exch_faq.htm
>
> <asti...@my-deja.com> wrote in message
news:8rfd9j$t5v$1...@nnrp1.deja.com...
> > Hi,
> >
> > I am running Exchange 2000 on Windows 2000. I want to add a new SMTP
> > address to all users of the form <firstname>.<lastname>@company.com,
> > but cannot see a way to do this.
> >
> > Any ideas?
Chris Scharff [MVP]
On Thu, 05 Oct 2000 08:37:21 GMT, strategically shaved monkeys
watched in awe as asti...@my-deja.com wrote:
>Rich - I found this, but couldn't determine how to influence the part
>of the address before the @ symbol. Any hints?
%g.%s
--
Chris Scharff
Simpler-Webb, Inc.
Austin, TX
Exchange FAQ: http://www.swinc.com/resource/exch_faq.htm
Tools & Utilities: http://www.mail-resources.com/resources/search.cgi
asti...@my-deja.com
Thanks,
Andrew
In article <p5lotssqmhdj7e2kc...@4ax.com>,
"Chris Scharff [MVP]" <chris....@swinc.com.no.spam.please> wrote:
>
> On Thu, 05 Oct 2000 08:37:21 GMT, strategically shaved monkeys
> watched in awe as asti...@my-deja.com wrote:
>
> >Rich - I found this, but couldn't determine how to influence the part
> >of the address before the @ symbol. Any hints?
>
> %g.%s
>
Chris Scharff
On Thu, 05 Oct 2000 13:15:09 GMT, asti...@my-deja.com wrote:
>Chris - That worked a treat - where are those symbols defined?
In the Exchange 5.5 books online... don't know where (or if) they are
defined in Exchange 2000.
--
Chris Scharff, MVP-Exchange
Senior Systems Consultant
Simpler-Webb, Inc.
Exchange FAQ: http://www.swinc.com/resource/exch_faq.htm
E-Mail Resource Guide:
http://www.mail-resources.com/resources/search.cgi
Ed Crowley [MVP]
--
Ed Crowley MCSE+Internet MVP-Exchange
Tech Consultant
Compaq Corporation
Protecting the world from PSTs and Bricked Backups!
Exchange FAQ: http://www.swinc.com/resource/exch_faq.htm
<asti...@my-deja.com> wrote in message news:8rhepu$kra$1...@nnrp1.deja.com...
> Ed - So I export the users from the directory, manually add the new
> addresses into the export file and re-import. That correct? What about
> new users in the future?
> Thanks,
> Andrew
>
> In article <uD30uUjLAHA.278@cppssbbsa05>,
> "Ed Crowley [MVP]" <ej...@clownpenis.fart.pacbell.net> wrote:
> >
> > Directory import.
> > --
> > Ed Crowley MCSE+Internet MVP-Exchange
> > Tech Consultant
> > Compaq Corporation
> > Protecting the world from PSTs and Bricked Backups!
> > Exchange FAQ: http://www.swinc.com/resource/exch_faq.htm
> >
> > <asti...@my-deja.com> wrote in message
> news:8rfd9j$t5v$1...@nnrp1.deja.com...
> > > Hi,
> > >
> > > I am running Exchange 2000 on Windows 2000. I want to add a new SMTP
> > > address to all users of the form <firstname>.<lastname>@company.com,
> > > but cannot see a way to do this.
> > >
> > > Any ideas?
> > > Thanks,
> > > Andrew
> > >
> > >
Ed Crowley [MVP]
finally added this feature. Some of us have been clamoring for it for four
years.
Chris Scharff [MVP]
On Sat, 7 Oct 2000 20:45:04 -0700, strategically shaved monkeys
watched in awe as "Ed Crowley [MVP]" <ej...@pacbell.net> wrote:
>Oops, sorry. I missed that you were asking about Exchange 2000. Microsoft
>finally added this feature. Some of us have been clamoring for it for four
>years.
Yeah right.... so then they turned around & removed the directory
import/export features. Um... thanks.
Rich Matheisen [MVP]
>On Sat, 7 Oct 2000 20:45:04 -0700, strategically shaved monkeys
>watched in awe as "Ed Crowley [MVP]" <ej...@pacbell.net> wrote:
>
>>Oops, sorry. I missed that you were asking about Exchange 2000. Microsoft
>>finally added this feature. Some of us have been clamoring for it for four
>>years.
>
>Yeah right.... so then they turned around & removed the directory
>import/export features. Um... thanks.
Ummm, Exchange doesn't HAVE a directory any more!
You'll find that the job has now been moved to the AD and uses LDIF,
rather than CSV, files. Q237677 is a good starting point, but a query
of Technet for "LDIFDE" will turn up several more KB articles,
Chris Scharff [MVP]
watched in awe as "Rich Matheisen [MVP]"
<rich...@rmcons.com.NOSPAM.COM> wrote:
>"Chris Scharff [MVP]" <chris....@swinc.com.no.spam.please> wrote:
>
>>On Sat, 7 Oct 2000 20:45:04 -0700, strategically shaved monkeys
>>watched in awe as "Ed Crowley [MVP]" <ej...@pacbell.net> wrote:
>>
>>>Oops, sorry. I missed that you were asking about Exchange 2000. Microsoft
>>>finally added this feature. Some of us have been clamoring for it for four
>>>years.
>>
>>Yeah right.... so then they turned around & removed the directory
>>import/export features. Um... thanks.
>
>Ummm, Exchange doesn't HAVE a directory any more!
Yes, it does. It's just managed by another group. Exchange without a
directory would be pretty worthless.
>You'll find that the job has now been moved to the AD and uses LDIF,
>rather than CSV, files. Q237677 is a good starting point, but a query
>of Technet for "LDIFDE" will turn up several more KB articles,
I know what tools Microsoft wants you to use to do this, but there's
no way I consider ldifde easier to use than the Exchange admin
directory import and export.
I sat down and played with ldifde again just now thinking that perhaps
i was being unreasonable in my assessment of the new tools. Um... if
they are easier to use than apparently I'm not even close to being the
brightest bulb on the tree.
In Exchange 5.5 if I wanted to change the zip code for a group of
users I would do the following:
1. fire up header.exe to find the field name for zip code (or look in
books online).
2. Do a directory export of all mailboxes in the site with that field
added to the default csv export file.
3. Open Excel & sort by zip code.
4. Delete out all entries which contained a zip code which didn't need
to be changed.
5. Do a global find & replace of the zip or delete the values and
paste in the new zip.
6. Do a directory import of the modified entries.
Now if I was fancy, I could have used command line admin /e and admin
/i, but I'm not, so I used the GUI in the Exchange admin.
Seriously Rich, would you tell me the steps to do the same thing in
Windows 2000? (Count this as my odd question for the day)
Rich Matheisen [MVP]
"Chris Scharff [MVP]" <chris....@swinc.com.no.spam.please> wrote:
>On Sun, 08 Oct 2000 13:13:50 -0400, strategically shaved monkeys
>watched in awe as "Rich Matheisen [MVP]"
><rich...@rmcons.com.NOSPAM.COM> wrote:
>
>>"Chris Scharff [MVP]" <chris....@swinc.com.no.spam.please> wrote:
>>
>>>On Sat, 7 Oct 2000 20:45:04 -0700, strategically shaved monkeys
>>>watched in awe as "Ed Crowley [MVP]" <ej...@pacbell.net> wrote:
>>>
>>>>Oops, sorry. I missed that you were asking about Exchange 2000. Microsoft
>>>>finally added this feature. Some of us have been clamoring for it for four
>>>>years.
>>>
>>>Yeah right.... so then they turned around & removed the directory
>>>import/export features. Um... thanks.
>>
>>Ummm, Exchange doesn't HAVE a directory any more!
>
>Yes, it does. It's just managed by another group. Exchange without a
>directory would be pretty worthless.
Picky, picky . . . What I meant was that there is no longer an
EXCHANGE directory.
>>You'll find that the job has now been moved to the AD and uses LDIF,
>>rather than CSV, files. Q237677 is a good starting point, but a query
>>of Technet for "LDIFDE" will turn up several more KB articles,
>
>I know what tools Microsoft wants you to use to do this, but there's
>no way I consider ldifde easier to use than the Exchange admin
>directory import and export.
>
>I sat down and played with ldifde again just now thinking that perhaps
>i was being unreasonable in my assessment of the new tools. Um... if
>they are easier to use than apparently I'm not even close to being the
>brightest bulb on the tree.
Well, it *is* LDAP, after all, Chris. This all goes on one line, but
it's neater putting each parameter on a separate line:
ldife
-f c:\temp\export.ldf
-s <server>
-d "CN=users,DC=<domain>,DC=<tld>"
-p subtree
-r "(&(objectCategory=person)(objectClass=organizationalPerson))"
-l "postalCode"
What that'll get you is a LDIF file with the format:
dn: <theobject's distinguished name>
changetype: add
postalCode: <some value>
Now, I can see where you'd be upset if all you had in your toolbag was
Excel and Access, 'coz they only know how to deal with two-dimentional
files (rows and columns) in the traditional database format. LDIF
files are just text files.
If I were to do what you want to do I'd probably spend a little time
and {ta-da} write a Perl (or VBS) script to either read the LDIF file
and rewrite it for import use, or modify the directory in-place.
Here's one (I haven't actually run this to verify that it works!) that
should read that LDIF file and rewrite it, suitable of use as an
import:
open(LDIF_I, $ldifi_file) or die "cannot open LDIF file: $!";
open(LDIF_O, ">$ldifo_file") or die "cannot open LDIF file: $!";
while (my $l = <LDIF>){
dumpit(\@lines) if ($l =~ /dn: /)
push (@lines, $l);
}
close LDIF_I;
close LDIF_O;
sub dumpit(){
$lines = $@;
foreach $x ($$lines){
if ($x =~ /postalCode:/){
($p, $pcode) = split (/:/, $x);
if ($pcode == 12345 || $pcode eq "12345"){
$pcode = 98765;
}
$x = join($x, ": ");
} else {
$x =~ s/changetype: add/changetype: modify/i);
}
print LDIF_O, $x;
}
}
>In Exchange 5.5 if I wanted to change the zip code for a group of
>users I would do the following:
>
>1. fire up header.exe to find the field name for zip code (or look in
>books online).
Fire up LDP.EXE and find the property.
>2. Do a directory export of all mailboxes in the site with that field
>added to the default csv export file.
You can modify the LDAP query to export only the objects that need
changing. No need to export them all.
"(&(objectCategory=person)(objectClass=organizationalPerson))"
becomes (for example):
"(&(objectCategory=person)(objectClass=organizationalPerson)(postalCode=12345))"
>3. Open Excel & sort by zip code.
Sorry, but you'll have to use a different skill set here. If this were
Unix, I'd suggest using "sed" and not have to write any code at all.
>4. Delete out all entries which contained a zip code which didn't need
>to be changed.
I'd never export 'em with LDIFDE.
>5. Do a global find & replace of the zip or delete the values and
>paste in the new zip.
This is where the new set of tools comes into play.
>6. Do a directory import of the modified entries.
>
>Now if I was fancy, I could have used command line admin /e and admin
>/i, but I'm not, so I used the GUI in the Exchange admin.
>
>Seriously Rich, would you tell me the steps to do the same thing in
>Windows 2000? (Count this as my odd question for the day)
Not an odd question. And I know you'll say the new way of doing this
is too hard, but it really isn't -- it's not harder, just different.
Chris Scharff [MVP]
>"Chris Scharff [MVP]" <chris....@swinc.com.no.spam.please> wrote:
>
>>On Sun, 08 Oct 2000 13:13:50 -0400, strategically shaved monkeys
>>watched in awe as "Rich Matheisen [MVP]"
>><rich...@rmcons.com.NOSPAM.COM> wrote:
>>
>>>"Chris Scharff [MVP]" <chris....@swinc.com.no.spam.please> wrote:
>>>
>>>>On Sat, 7 Oct 2000 20:45:04 -0700, strategically shaved monkeys
>>>>watched in awe as "Ed Crowley [MVP]" <ej...@pacbell.net> wrote:
>>>>
>>>>>Oops, sorry. I missed that you were asking about Exchange 2000. Microsoft
>>>>>finally added this feature. Some of us have been clamoring for it for four
>>>>>years.
>>>>
>>>>Yeah right.... so then they turned around & removed the directory
>>>>import/export features. Um... thanks.
>>>
>>>Ummm, Exchange doesn't HAVE a directory any more!
>>
>>Yes, it does. It's just managed by another group. Exchange without a
>>directory would be pretty worthless.
>
>Picky, picky . . . What I meant was that there is no longer an
>EXCHANGE directory.
I'm really not trying to be all that picky... There is an Exchange
directory, it's called AD. If Bob's Software had developed a new
product which utilized AD and didn't write a good tool to
manage/maintain the entries it needed/used in AD, the people who
bought Bob's Software would be asking why they didn't write tools to
make the product easier to use... just because MS made both Exchange
and the directory it uses, doesn't mean that the Exchange team is off
the hook for making a good set of tools to manage the directory. If
they want to push off that responsibility on the AD group, I guess
that's their right, but Microsoft makes both products, so the problem
is still Microosft's.
>>>You'll find that the job has now been moved to the AD and uses LDIF,
>>>rather than CSV, files. Q237677 is a good starting point, but a query
>>>of Technet for "LDIFDE" will turn up several more KB articles,
>>
>>I know what tools Microsoft wants you to use to do this, but there's
>>no way I consider ldifde easier to use than the Exchange admin
>>directory import and export.
>>
>>I sat down and played with ldifde again just now thinking that perhaps
>>i was being unreasonable in my assessment of the new tools. Um... if
>>they are easier to use than apparently I'm not even close to being the
>>brightest bulb on the tree.
>
>Well, it *is* LDAP, after all, Chris.
Yes and I understand the basics of LDAP Rich, but it's not all that
easy to work with without good programming skills, or a good tool.
>This all goes on one line, but
>it's neater putting each parameter on a separate line:
>
>ldife
> -f c:\temp\export.ldf
> -s <server>
> -d "CN=users,DC=<domain>,DC=<tld>"
> -p subtree
> -r "(&(objectCategory=person)(objectClass=organizationalPerson))"
> -l "postalCode"
>
>What that'll get you is a LDIF file with the format:
>
> dn: <theobject's distinguished name>
> changetype: add
> postalCode: <some value>
>
>Now, I can see where you'd be upset if all you had in your toolbag was
>Excel and Access, 'coz they only know how to deal with two-dimentional
>files (rows and columns) in the traditional database format. LDIF
>files are just text files.
Yes, well, I suppose I could open the file and do a global find and
replace in this instance, although in others it might not be
desirable. I think it would be best to actually make the changes using
ADSI rather than LDIF, would you think that as well?
>If I were to do what you want to do I'd probably spend a little time
>and {ta-da} write a Perl (or VBS) script to either read the LDIF file
>and rewrite it for import use, or modify the directory in-place.
Yes well, here my weak programming skills again bite me in the ass. I
am working on it though, I swear.
Well, this is good to know, I shall file that away for later.
>>2. Do a directory export of all mailboxes in the site with that field
>>added to the default csv export file.
>
>You can modify the LDAP query to export only the objects that need
>changing. No need to export them all.
This is good to know as well... see Microsoft's examples are often a
bit too basic to really help you get to the meat of the problem. I
will experiment with this a bit more in the future to see what other
kinds of things one might want to do as well.
> "(&(objectCategory=person)(objectClass=organizationalPerson))"
>becomes (for example):
>
>"(&(objectCategory=person)(objectClass=organizationalPerson)(postalCode=12345))"
>
>>3. Open Excel & sort by zip code.
>
>Sorry, but you'll have to use a different skill set here. If this were
>Unix, I'd suggest using "sed" and not have to write any code at all.
Ok... so I ftp the file to a unix box and use sed, or write a
vbscript.
>>4. Delete out all entries which contained a zip code which didn't need
>>to be changed.
>
>I'd never export 'em with LDIFDE.
True and that is definitely an advantage of the new method...
especially for large companies.
>>5. Do a global find & replace of the zip or delete the values and
>>paste in the new zip.
>
>This is where the new set of tools comes into play.
>
>>6. Do a directory import of the modified entries.
>>
>>Now if I was fancy, I could have used command line admin /e and admin
>>/i, but I'm not, so I used the GUI in the Exchange admin.
>>
>>Seriously Rich, would you tell me the steps to do the same thing in
>>Windows 2000? (Count this as my odd question for the day)
>
>Not an odd question. And I know you'll say the new way of doing this
>is too hard, but it really isn't -- it's not harder, just different.
It's not "too hard" in an academic sense. But I think it has a certain
pain in the ass factor associated with it when compared to how it was
done previously. I think anything which people do on a day to day
basis & requires resorting to writing code to achieve is something
which needs to be automated.
Now of course this does present a nice opportunity for a 3rd party to
come in and design a good tool to do this... personally, I think that
Microsoft should have created the tool and included it with the
product. I think the ball was dropped here. You of course are welcome
to disagree, and we can debate it tomorrow over a beer. <g>
Rich Matheisen [MVP]
[ snip ]
>>>>Ummm, Exchange doesn't HAVE a directory any more!
>>>
>>>Yes, it does. It's just managed by another group. Exchange without a
>>>directory would be pretty worthless.
>>
>>Picky, picky . . . What I meant was that there is no longer an
>>EXCHANGE directory.
>
>I'm really not trying to be all that picky... There is an Exchange
>directory, it's called AD.
Only because it's tied to the AD. I suspect that they could have just
as easily used another directory. But it's still not an Exchange
directroy -- Exchange just uses it as a convenient place to park its
data.
>If Bob's Software had developed a new
>product which utilized AD and didn't write a good tool to
>manage/maintain the entries it needed/used in AD, the people who
>bought Bob's Software would be asking why they didn't write tools to
>make the product easier to use... just because MS made both Exchange
>and the directory it uses, doesn't mean that the Exchange team is off
>the hook for making a good set of tools to manage the directory. If
>they want to push off that responsibility on the AD group, I guess
>that's their right, but Microsoft makes both products, so the problem
>is still Microosft's.
But those tools you speak of didn't exist in Exchange 5.5, either. Nor
did they exit in any of the NT domain managmement tools. Where's the
MS tools to collapse NT Domains into AD OU's? Where's the tools to
move computers between E2K AG's? If we're gonna be painting with a
broad brush, then okay -- let's go!
[ snip ]
>>Well, it *is* LDAP, after all, Chris.
>
>Yes and I understand the basics of LDAP Rich, but it's not all that
>easy to work with without good programming skills, or a good tool.
>
>>This all goes on one line, but
>>it's neater putting each parameter on a separate line:
>>
>>ldife
>> -f c:\temp\export.ldf
>> -s <server>
>> -d "CN=users,DC=<domain>,DC=<tld>"
>> -p subtree
>> -r "(&(objectCategory=person)(objectClass=organizationalPerson))"
>> -l "postalCode"
>>
>>What that'll get you is a LDIF file with the format:
>>
>> dn: <theobject's distinguished name>
>> changetype: add
>> postalCode: <some value>
>>
>>Now, I can see where you'd be upset if all you had in your toolbag was
>>Excel and Access, 'coz they only know how to deal with two-dimentional
>>files (rows and columns) in the traditional database format. LDIF
>>files are just text files.
>
>Yes, well, I suppose I could open the file and do a global find and
>replace in this instance, although in others it might not be
>desirable. I think it would be best to actually make the changes using
>ADSI rather than LDIF, would you think that as well?
That's what I alluded to when I said "or modify the directory
in-place" (see below). Although, for this kind of work I'd use ADSI,
LDAP, and ADO rather than just ADSI and LDAP.
It's a lot easier to deal with large sets of data in terms of a
database. E.g.,
$objADOconn = Win32::OLE->new("ADODB.Connection");
$objADOconn->{'Provider'} = "ADSDSOObject";
$objADOconn->Open("ADs Provider");
$ExServ = "MyServer.domain.com";
$ExOrg = "MyOrg";
$adsiRoot = "<LDAP://$ExSrv/o=$ExOrg>";
$strADOQueryString =
"$adsiRoot;(&(objectCategory=person)(objectClass=organizationalPerson));postalCode";
$objRS = $objADOconn->Execute($strADOQueryString);
$objRS->MoveLast; # force the recordset to finish the query
$objRS->MoveFirst; # if more rows are pending
while (!$objRS->{EOF}){
< whatever processing you deem necessary >
< on the $objRS->Fields("postalCode")->{'Value'} >
}
>>If I were to do what you want to do I'd probably spend a little time
>>and {ta-da} write a Perl (or VBS) script to either read the LDIF file
>>and rewrite it for import use, or modify the directory in-place.
>
>Yes well, here my weak programming skills again bite me in the ass. I
>am working on it though, I swear.
It's a common weakness in NT folks, Chris. MS has never emphasised
scripting as "the" way to do things. They've preferred GUI's for
damned near everything. I've ranted about that before. If there's
something that must be done over and over again, it should be
scripted. Keep the GUI for "one time" tasks, or abandon it entirely.
I can't think of one Unix admin that would not use shell scripting (or
Perl, AWK, etc.) to accomplish this task.
[ snip ]
>>>In Exchange 5.5 if I wanted to change the zip code for a group of
>>>users I would do the following:
>>>
>>>1. fire up header.exe to find the field name for zip code (or look in
>>>books online).
>>
>>Fire up LDP.EXE and find the property.
>
>Well, this is good to know, I shall file that away for later.
Get used to using LDP a lot. ADSIEdit, too. You can use either to
change things in the directory.
[ snip ]
>>>3. Open Excel & sort by zip code.
>>
>>Sorry, but you'll have to use a different skill set here. If this were
>>Unix, I'd suggest using "sed" and not have to write any code at all.
>
>Ok... so I ftp the file to a unix box and use sed, or write a
>vbscript.
I think sed may be one of the tools in the Unix tools add-on to W2K.
MS's direction seems to favor VBS over small, single purpose, tools
like AWK, sed, grep, fgrep, etc.
[ snip ]
>>Not an odd question. And I know you'll say the new way of doing this
>>is too hard, but it really isn't -- it's not harder, just different.
>
>It's not "too hard" in an academic sense. But I think it has a certain
>pain in the ass factor associated with it when compared to how it was
>done previously.
I've never been satisfied using Excel (originally it had a 256
character cell limit, it still drops the last column on export to CSV
if it's empty, etc.). And VBS, without all the latest bells and
whistles, is pretty lame (in fact, it's pretty lame even WITH them).
>I think anything which people do on a day to day
>basis & requires resorting to writing code to achieve is something
>which needs to be automated.
It should be. But, have you seen it automated in any release of
Exchange? I haven't. How about NT or W2K? Same answer, right?
> Now of course this does present a nice opportunity for a 3rd party to
>come in and design a good tool to do this...
I suspect that's what MS thinks, too. They've always said they're
building the platform, not the complete solution.
>personally, I think that
>Microsoft should have created the tool and included it with the
>product. I think the ball was dropped here. You of course are welcome
>to disagree, and we can debate it tomorrow over a beer. <g>
Sounds like a plan, Chris.