Archive for the ‘microsoft’ Category

Linking Access to an Exchange or Outlook Table – Mapi Tags and Schema.ini

May 23, 2007

This is basically a note to myself, because I did it a few years ago and have broken the table links. It’s no fun to find all the old documentation, so I’m noting the main points here.

Access 2000 uses the Jet IISAM to link an Access table to Outlook or Exchange. It generates a file called Schema.ini that basically tells IISAM what columns in the MAPI store will map to the columns in your linked table in Access.

Normally the schema.ini file is generated automatically, but if your MAPI table contains custom outlook forms, then these will break the linking between Access and Outlook (or Exchange). In this case, you need to modify the schema.ini file manually. There was a nice article about how to do this in Smart Access (Aug 2000) which Microsoft has reprinted here. There is reference to a second article which is more difficult to find called Accessing Exchange: Delving a Little Bit Deeper into the Jet 4.0 IISAM which describes how to use the MDBVUE.EXE tool, which I’ve summarized here with changes specific to my project.

Here is a typical schema.ini file that helps Access connect to a folder called Billing Contacts in the Public Folders:

[1 – Outlook – Billing Contacts]
IdBytes=00 00 00 00 1A 44 73 90 AA 66 11 CD 9B C8 00 AA 00 2F C4 5A 03 80 85 13 1D 62 85 DE C9 40 93 7D B3 C9 B9 34 DC EA 00 00 00 00 FF 85 00 00
Col1=”Message Class” Char Width 510 Tag 1703966
Col2=Title Char Width 510 Tag 974585886
Col3=Account Char Width 510 Tag 7340062
Col4=”File As” Char Width 510 Tag -2120286178
Col5=”Home Address” Char Width 510 Tag -2137194466
Col6=”Business Address” Char Width 510
Col7=Phone Char Width 510
Col8=”Mobile Phone” Char Width 510
Col9=”Home Phone” Char Width 510

The article goes over the structure of the file, but the part I forgot was how to generate the “Tag” attribute for the non-standard fields. You actually need to dig into the guts of the MAPI store to find it.

“The Tag value in the Schema.ini file combines the DISPID of the column (a unique number that’s assigned to each column) in the top two bytes, and the datatype from Table 3 in the bottom two bytes.” (Table 3 is in the article, which is reproduced on Microsoft’s website but you don’t actually need the table, because MDBVUE will tell you the value.)

You then need to use MDBVUE.EXE tool from Microsoft to open the MAPI store and examine the DISPID and the DATATYPE directly.

One of the broken columns in my linked table was the “Home Address” column, which looked like this in the previous schema.ini file:

Col5=”Home Address” Char Width 510 Tag -2137194466

I needed to calculate the new Tag using the MDBVUE tool. After connecting to the store, open one of the actual items within the IPM folder (in this case one of the contacts withing Billing Contacts) and click on the Property Interface button, which opens another window. At the bottom of the window, select Hex. Find a row with what looks like a home address. The left column contains the DISPID (red circled in the screenshot, value is 0X8095) and the center column contains the datatype (red circled, value is 0X001E).

Screenshot of browsing an Item with MDBVUE Screenshot of Item Properties window in MDBVUE

Concatenated, these values are 0X8095001E and converting to signed long integer, this is -2137718754 . Note: you can convert using the Immediate Window in Visual Basic (open Access > Tools > Macro > Visual Basic Editor… then in the editor >View > Immediate Window, and type into the Immediate Window print &H8095001E and hit Enter to see the converted value.


So that row in the schema.ini file becomes:

Col5=”Home Address” Char Width 510 Tag -2137718754


Repeat with the other custom entries in the schema.ini file and save. The restart Access and open the linked table to see if it works.



Moving Exchange Server

April 29, 2007

Migrating from MS Exchange 2000 to 2003 this weekend, and thought I’d note a few of the not-so-obvious things I’ve come across. Hope it helps someone.

I built a small business network way back in 2001 to support a law practice, and the public folders on the MS Exchange 2000 Server are the hub of the case management, workflow, consultation scheduling. Because the end users felt comfortable using Outlook, it’s custom forms are basically the front end to all the other systems, including financials. It’s mission-critical, to say the least.

Like most small offices, we saved by purchasing one win2k server and making it do everything: domain controller, file server, exchange, etc., and with a handful of users, life was good and administration was simple. (we bought and stored an identical server offsite for disaster recovery).
Fast forward a few years, and the do-everything server is really grinding to fulfill its basic mission. I considered replacing the original server with a new Small Business Server 2003 setup.

Issue 1: SBS does not coexist with other domain controllers. Well, this actually is a myth, but I didn’t feel like messing with the AD, seizing FSMO roles. Plus why shove all the work on a single box again? But here’s how from Microsoft.

OK, so the plan was this:  get a second server, set it up as a member server for Exchange 2003, migrate the users’ mailboxes and mission-critical public folders.  Then decommission the Exchange 2000 server but retain it as the DC and fileserver.

We bought a Dell PowerEdge SC440 (what a deal), and I prepped it at home: installed Server 2k3 Standard and did not join to a domain. Brought it to the office and plopped on the network.  For a small organization, this can work, even thought the recommended hardware would consist of 6 or more disks: mirrored OS, mirrored logs, raid 5 exchange database.  SC440 only officially holds 2 disks, but has SATA connectors for 4.  Hmm.  Squeeze ’em into the empty floppy and second optical bay!  So OS and logs are on one disk set, with separate partitions, and Exchange database is on the second mirror set.  It’ll suffice.

Issue 2: it would not join the domain! Logged on locally as the Administrator, tried to join the domain with matching domain admin credentials, and get a goofy error such as “this account is not authorized to log in from this workstation.” Note: if your local admin account matches the domain admin account, just leave the credentials blank when it prompts you for them. Works.

Now I’m ready to install Exchange 2003 on the new box, right?  Sort of.  First you have to prepare the existing AD on all the other domain controller(s).  (BACK IT UP FIRST!).  The install walks you throug it: DNSdiag, Forestprep, Domainprep.  It was fairly painless.  There is an excellent reference here.  After the install, use Exchange System Manager to move the default Exchange database and log locations to the intended disks.

Exchange 2003 is in.  Now, how to get the folders over from the old Exchange 2000 server?  In ESM, it’s as simple as “move mailbox” to migrate the users.  The public folders have to be “replicated,” and this can take a while.  It’s doing this while I write.