A lot of times I need to open a CSV file and do something with the content. Instead of opening the text file from VBScript, reading every line and parsing the content you can treat the CSV file as a database table. The only thing you need to do is to use the Microsoft Text Driver.

Suppose you have a file called C:\EXPORT\GALSYNC.CSV. The file contains a header line like below:

Alias Name, Display Name, E-Mail Address

Following the header line, the lines with data follow. For example:

“YDHS665”,”Joe User”,bla@bla.com

To use this file as a database table, consider the simple code below:

strConnectionString="Driver={Microsoft Text Driver (*.txt; *.csv)};Dbq=c:\export\;Extensions=csv;"
Set objConnection=CreateObject("ADODB.Connection")
objConnection.Open strConnectionString
strSqlString="select * from galsync.csv"
Set objRS=objConnection.Execute(strSqlString)

Do While not objRS.eof

 wscript.echo objRS(“Alias Name”)
 wscript.echo objRS(“Display Name”)
 wscript.echo objRS(“E-Mail Address”)
 objRS.MoveNext

Loop

You can influence the behavior of the Microsoft Text Driver by creating a schema.ini file in the same directory as your CSV files. For more information about schema.ini, look here.

It is a common misconception that you need to install Outlook on an Exchange 2003 Server to create profiles and to be able to send e-mails with MAPI. There are multiple ways to do it but the easiest method is to use newprof.exe.

Newprof needs a prf file that contains enough settings to create a profile with. You can run newprof -s to run in it interactive mode so you can select the prf file to use.

After your profile is created, applications on the server can use the profile to send mail:

Set objSession=CreateObject(“MAPI.Session”)
objSession.Logon “PROFILENAME”
Set objMessage=objSession.Outbox.Messages.Add
objMessage.Subject=”….”
objMessage.Text=”…”

The code above is not complete but I just want to show that code like this DOES NOT REQUIRE OUTLOOK on the Exchange 2003 Server. In fact, it is not supported by Microsoft that you do.

File Attachment: newprof.zip (23 KB)

I had to configure replication between Exchange 5.5 and Active Directory using the Active Directory Connector (ADC). We are doing an intra-organizational migration which means we just install a new Exchange 2003 server in an existing Exchange 5.5 site. To do this, you have to configure the ADC first with replication connection agreements according to the steps presented in the ADC Tools.

Basically, when you migrate like that, you perform the following steps:

1) Forestprep
2) Domainprep
3) Install ADC
4) Configure ADC with ADC Tools
5) Install first Exchange 2003 server (includes the SRS)

Not too complex in reality.

Ok, so I configure the AD using the ADC Tools and everything works fine. Not a single error from the ADC. Logical because that was well prepared and the ADC Tools do a great job holding your hand.

However, the ADC replicates the Display Name of an Exchange 5.5 mailbox to the display name AND cn of the matching AD object. The display name in AD needs to be the same as in Exchange 5.5 or you will have different address books. But replicating display name to the cn (according to me) is not required to properly migrate. So of course, because the customer has all sorts of applications that actually depend on the cn and dn of the AD object, several applications just broke.

The customer’s developers fixed the applications amazingly quickly so all issues were resolved a little bit before 9 ‘o clock but it was close.

So, like in any project, go over all the details of the migration and check if custom applications don’t depend on any of the changed properties. This can be anything because if you have an application that depends on, say, the department name in AD and values in Exchange 5.5 are different from AD, you have the same problem.

Actually, Microsoft should not have made this the default behaviour. It is also very easy to prevent, just check this KB article.

Go over to weeklyradioaddress.com and listen to a few of them. Great parody on George W. Especially this one is funny.

At the moment, I am busy with an  Exchange 2003 migration project. The project includes secure access to Outlook Web Access, Outlook Mobile Access and Server ActiveSync. We use load-balanced ISA 2004 servers, load-balanced front-end servers and clustered Exchange 2003 back-end servers.

The ISA 2004 servers are installed in a workgroup and are connected to an external DMZ. To provide user authentication, ISA server can be configured with forms-based authentication in combination with RADIUS. A RADIUS server is required and we use Microsoft’s IAS.

This solution requires ISA 2004 with SP1 as discussed in KB article 884560. The user can then connect to https://serverFQDN/exchange. ISA will present the FBA form (which by the way, can be customized) and the user types the username and password on the AD domain. ISA will then use RADIUS to authenticate the user. You should use IPSEC or something similar to encrypt this traffic, because this solution only supports PAP, SPAP and CHAP.

After ISA has verified your credentials, access to the front-end servers is granted. If you configure the publishing rule to forward authentication credentials, no additional authentication dialogs will be shown to the user. This works really well and it allows you to use ISA servers not part of the domain and still use AD authentication.

Of course, you can hardly call the above solution secure because it depends on the user’s password. Most companies will require two-factor authentication.

ISA 2003 natively supports RSA SecurID but many other solutions are used. One such solution is Aladdin’s eToken with OTP (one-time password). To authenticate, RADIUS is used again but instead the user supplies the username and OTP from the token. This is checked against a replicated user account in a shadow domain that contains all the information about the eToken, seed values etc… The advantage of using a shadow LDAP directory (can be AD or ADAM) is that the production forest does not need schema extensions but that you can still use AD management tools in the production domain to configure users for OTP etc…

But now we have a problem. The user can specify the username and OTP in the ISA form, but the response from the RADIUS server is not recognized because it is not what ISA server expects. This will soon be solved by Aladdin (we hope). Another question is whether or not this solution will support forwarding the user’s credentials to the front-end server. I expect not so we will have to see if this will be a good solution.

Anyone with a good solution? Other products and technologies to recommend? Anyone???

Well, DEP stands for Data Execution Prevention and is a technique that prevents code execution from certain memory locations. This support article contains all you need to know about it from a sysadmin perspective.

Probably, it is best to have hardware-assisted DEP but then you need a processor that supports it. Both AMD and Intel have such processors.

I came accross DEP while I was reading an article about boot.ini switches for Exchange 2003. Apparently, it is now recommended to run Exchange 2003 with the PAE kernel (/pae in boot.ini) when you run Exchange 2003 on Windows 2003 SP1. When you use /PAE, you also enable DEP on hardware that supports it. Be aware that PAE is sometimes automatically enabled.

You should realize that Exchange 2003 cannot take advantage of memory above 4GB, even with PAE enabled. It just was not designed to handle that, unlike SQL Server.

When I needed to create a storage group design for an Exchange enterprise server, I always used the guideline of not creating the full amount of storage groups at once. For example: when I would have 8 databases, I would use 2 storage groups. The reason for this is that Microsoft recommended this approach because of the negative effects on memory etc…

This seems to have changed from Exchange 2000 SP3. Microsoft now recommends to work the other way around. So when you have 8 databases, you would create 4 storage groups. Something like this:

SG1: DB1, DB5

SG2: DB2, DB6

SG3: DB3, DB7

SG4: DB4, DB8

This is discussed in knowledge base article 890699.