The Mole #22: Technical Answers from Inside Microsoft - Updated InterOrg Tool, Multi-boot, Kixtart

  • Article

November 22, 1999

Editors Note The questions and answers below are from the Inside Microsoft column that appears regularly on the TechNet Web site at the following location: https://www.microsoft.com/technet/community/columns/insider/default.mspx. To find out how to submit questions of your own, see the end of this article or go to https://www.microsoft.com/technet/community/columns/insider/default.mspx.

The TechNet Mole provides expert answers from deep within Microsoft to questions from IT professionals. This installment focuses on these issues:

  • The latest InterOrg Synchronization Tool, download it here

  • Singin' those multi-boot blues

  • Gimme code: Domain-wide file checking with Kixtart

On This Page

For your Downloading Pleasure: orgsynch.exe
Singin' those old multi-boot blues
Gimme Code: Domain-wide file checking with Kixtart
Got Questions? Mail the Mole
Credits

For your Downloading Pleasure: orgsynch.exe

Hi Mole,

I am testing the InterOrg tool (from the BackOffice Resource kit, 2nd ed.), and have had no luck in getting it to populate the containers. Mail does flow over SMTP to the sites from the requestor, and I have seen the .mdb attachments in each mail. It looks like Requestor service is working OK, but Master is not. I did everything exactly as in document several times with fresh installation of Windows NT Server 4® (with service pack 3 & 5 ) and Exchange Server (with and without SP2).

I found that other people have the same problem. Is any solution for this problem?

Vadim Shalenkov, MCSE, Network Administrator

Dear Vadim,

You're obviously up to speed on this utility. For those less in the know, a little background before we move on to your question. The InterOrg Synchronization tool lets multiple Microsoft Exchange Server organizations synchronize the contents of their directories. The connector works hierarchically, with a Master service running in the master organization and Requestor services running in the branch organizations. The Microsoft Exchange Server computer in the master organization collects and distributes all of the directory changes from the branches. The Requestor service in each branch organization has two jobs—first, collecting directory changes for that organization and exporting them to the Master service and second, receiving and storing the updated directory information sent from the Master service.

The Master agent processes all Requestor service messages immediately, but it can take at least 24 hours for changes to replicate throughout the system.

That's how it's supposed to work, anyway. Mole did considerable digging, without finding anything specific that addresses the problem you report. His burrowing did unearth a little gem to share with his faithful readers, though—a brand new version of the ORGSYNCH executable, which you can download below:

Click here to copy orgsynch.exe to your computer

With luck and right living, it may be that simply having an updated version of the utility will solve the problem.

You might want to review the Knowledge Base article **198789:**Installing, Configuring, and Using the InterOrg Synchronization Tool, just to make doubly sure that all your ducks are in a row.

Then, obtain the Knowledge Base article **198798:**Troubleshooting the InterOrg Synch Tool for further reference.

And here's another tip: The InterOrg Synch tool performs better if Microsoft Access 9.x and Microsoft Outlook 9.x are installed on the Exchange Server computers that participate in InterOrg replication after the tool has been installed. Also, be sure to install the latest ODBC drivers from the Microsoft Universal Data Access Web site, located at https://www.microsoft.com/data/download.htm.

The latest ODBC drives are an essential part of the Microsoft Data Access Components (MDAC). It may seem we're wandering far from the original dilemma, but in networks, as in the universe at large, all things are related. Read up on the ODBC drives on the MDAC website. Then take a breath and intone after Mole--OHM.

Finally, just in case we're dealing with a case of mistaken identity, Mole adds this caution. There were a few "anomalies" fixed in Exchange Service Pack 3 relating to the InterOrg Replication utility. Now, the InterOrg Replication utility from Exchange Service Pack 2 is not the same as the InterOrg Synchronization utility from the BackOffice Resource Kit (a.k.a "The BORK", which is not a Scandinavian pop group.).

Are we confused yet? It does seem unkind to give two distinct but similar utilities such seemingly interchangeable names. Rest assured, Mole will register his dissatisfaction with the "Utility Naming Board," in the hopes that future executables are christened with a bit more forethought. Anyway, Mole would just like to make sure that you know that there were some fixes in SP 3 for the InterOrg Replication utility. You can check out the fixes in SP3 for the InterOrg Replication Utility by checking the Knowledge Base—**241740:**List of Bugs Fixed in Exchange Server 5.5 Service Pack 3 (Part 2).

Got that?

Singin' those old multi-boot blues

Dear Mole

We here at Adobe Systems have a problem. We run multiple systems for support purposes of our own Products. The problem we have is we need to create a multi-boot environment for the applications for the support desk.

We need to be able to boot into either of the following systems on one machine

  • NT Server

  • NT Workstation

  • Windows 95

  • Windows 98

We have tried loading these on separate partitions. Server and workstation are fine with either one of the other Operating systems however we cannot get the system to run properly with 95 and 98 on the same computer.

Any help or pointers greatly appreciated,

Max Brown MCSE, Adobe Systems Europe

Hey, Max,

You're right, why run just one OS when you can boot up two, or three, or even more? It's a smart IT pro that makes efficient use of his or her machines. Don't overlook Windows 2000 Professional and Server, soon to be available, as well.

Okay, here's the thing.

While setting up a multi-boot machine using a combination of DOS, Windows 9x, Windows NT, and Windows 2000 is pretty straightforward (please see **217210:**Multi-Booting Windows 2000, Windows NT, Windows 95/98, and MS-DOS for the details), you need to decide which Windows OS you want to include on your multi-boot machine. Windows 95 and Windows 98 use the same boot file, so multiple booting Windows 95 and Windows 98 is not supported by Microsoft. Now, you could probably write a batch file that does some renaming as part of a reboot sequence, but that seems like it could turn into an internal support burden, and Mole guesses your plate's already quite full enough, thanks.

The most hassle-free solution is to use a third party application that takes care of the file switching magic. Here are some to get you started:

Remember, though, Mole doesn't endorse products—he just gives you a little nudge in the right direction from time to time. Do your research on "boot managers" and choose one that fits your needs."

And you, Dear Readers, if you have solutions, suggestions, or recommendations of your own, please send 'em along. Mole promises to share.

Gimme Code: Domain-wide file checking with Kixtart

Dear Mole,

I would like to be able to create a list of pc's in the domain, say using net view > pclist.txt, and then read from that file with Kixtart in order to check whether each PC has a particular file on it. However, I can't see any way within Kixtart to read a line from a file, nor can I see any utility within NT4 SP4 Resource Kit that can pass that data. Am I missing the point or an obvious solution?

Simon Lucas, International Help Desk Engineer, Royal Air Force Innsworth, UK

Dear Simon,

Clever of you to write Mole. He's found you a solution—to wit, the OPEN() function. The manual devotes a section to it. From page 61 (and Mole quotes):

OPEN

ActionOpens a text file.

Syntax: OPEN (file number, "file name", mode)

Parameters:

File numberA numeric expression indicating the file number of the file to open. Possible values range from 1 to 10.

File name

A string expression indicating the path and name of the ASCII file to open.

Mode

Optional parameter that indicates what should happen if the file does not exist. This parameter can have the following values:

0 If the file does not exist, OPEN fails with return code 2 (default).

1 If the file does not exist, OPEN will create a new file.2 Opens the file for read access (default).4 Opens the file for write access.

Note: These values are cumulative. So if you want to open a file for write access, and create it if it does not yet exist, you should specify 5. Notice however that a file cannot be opened for read and write access at the same time.

Here is some sample code for doing file reading:

 RUN "Net view /DOMAIN:domain > domain.txt"
 IF Open(2, "domain.txt")  = 0
 $x = ReadLine(2)
 WHILE @ERROR = 0
 <HERE is where you want to plug code in.>

Here is an example:

    ? "Line read: [" + $x + "]"
    $x = ReadLine(2)
 LOOP
 ENDIF
 Close (2)

At the end of one lucky tunnel, Mole found an absolutely fantastic Web site that you should add to your Favorites right away. It includes script samples, a bulletin board, "what's new", command reference, function reference, and everybody's favorite—much much more. Mole gives it two paws up. Check it out at Kixtart Web site https://kixtart.to/.

Code on, dude.

Got Questions? Mail the Mole

Communicate with Mole at [closed account]. Send him your toughest questions. And if you think you have a better answer than Mole's, or a different one, send that along, as well. Please include the following:

  • Your name

  • Your title

  • Your company

  • Your e-mail address

  • Your question/solution/compliment

Credits

Lon Collins. He's the man.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.