Exchange interchange II

We recently went from an NT 4.0 network to a Windows 2000 AD network, and migrated to an Exchange 2000 server. We are using MS Office XP, and are now getting A LOT of "Requesting Data" messages on the Outlook client. Mail services seem to be very slow, and I am not familiar enough with Exchange 2000 to know where to look first to correct this. Any suggestions would be appreciated.

I had this problem on my Exchange 5.5 as well. This caused by the Antivirus program. I started to notice this problem after I upgraded my AV program (CA?s InoculateIT) with their latest service pack, at that time. I was working with Microsoft and CA?s tech-support for almost 4 months to get to the bottom of this issue. To make the story short, finally we found out that the problem lies with the VAPI version 1.0. This version of VAPI was introduced with Exchange 5.5 service pack 3.
MS told us this issue was resolved with VAPI version 2.0. This version is only available in Exchange 2000/SP1.
After I upgraded to E2K I am not experiencing this issue.

Good luck.

I had the same problem with my Exchange 5.5 SP4 after upgrading my clients to MS Office XP (2002).
The file oxpauiu.exe I downloaded from Microsoft and executed on each client's PC solved the problem.

check your anti-virus setting. disable it and reboot to see whether you still experience the problem.

or click on http://tinyurl.com/8ian

If for some unknown reason you can't block the port, you could easily upgrade your Exchange server from NT 4.0 to Win2k, even on an NT 4.0 domain, provided the Exchange server isn't an NT 4.0 domain controller. Alternately, you could build a Win2k member server, install Exchange 5.5 in the same site, move your mailboxes etc.. -- given the choice between these options, I'd opt for building a second server, but that does cost $$$.

However, what you should do is close port 135 off from the Internet immediately. Quoting from the security bulletin "most machines attached to the Internet should have port 135 blocked. RPC over TCP is not intended to be used in hostile environments such as the Internet...Windows NT 4.0 users are strongly encouraged to employ the workaround discussed in the FAQ in the bulletin, which is to protect the NT 4.0 system with a firewall that blocks Port 135". There are always ways to work around leaving this port open. Even before this bulletin, leaving port 135 open was considered a very bad security practice.

We are running MS Small Business Server. Port 135 is not enabled in the Proxy server configuration. I believe this would make the server fairly secure from direct RPC attacks from the Internet, but is still vulnerable from RPC attacks borne by emailand web page content from the back side. Any thoughts on this?

Is there a way to test to see if port 135 is in fact open? Thanks!

Maybe I'm not understanding the question correctly, but how could you expect to Sync if you are offline?

Correct... if you are off-line you cannot synchronize with the exchange server. You must be connected. If the user is using Outlook as the client and opens it off-line, leaves it open and connects, Outlook will still be working off-line. The usermust close Outlook and re-open to connect and synchronize.

If you actually mean he can not synch when working remotely, then try the following:

1)Add a entry to the host file for the exchange server

2)change the binding order to use TCP first per MS article 163576

Are you using remote tools?

If you open Outlook, open remote tools and click on connect it will perform a mini/quick-sync.

By default on Outlook 2000, the mini-sync option syncs the following:

1. Calendar
2. Drafts
3. Outbox (So it will send any mail the user has created offline)
4. Inbox

Let us know how that goes.

You can find these tools in the Tools menu under remote mail.

To configure the mini-sync option click on Tools --> Offline Folder settings --> Quick Synchronization.

Hope this helps.

Spent a few minutes looking for it, and then found a knowledge base artice: 303513 XCON: How to Modify the POP or IMAP Banner. The article describes how to change the banner, but it didn't say anything about downloading a utility (something I could not find). Hope this helps.

Make sure they are in the same forest. Windows 2000 and Exchange 2000 don't support Exchange working across 2 forests. We learned this the hard way and are working on fixing it now. Windows 2003 doesn't have this problem, they brought in forest trusts to fix it.
Otherwise it should work fine. You just have to setup a new information store for the second domain, setup all the users (which shouldn't be hard since active directory should know them all), and then setup the mailboxes or migratethem in using the exchange migration tools.

My appologies, 135 does have to remain open. The ports I was refering to are listed in Q articals # Q278339 and Q280132.

Chris..

Yes it's possible and you would set that up through the Internet Mail Connector (IMC).
Here's an article from MS that may help you get started. Q264557
You will also have to setup MX records in DNS, one for each domain.
I currently run three site addresses on a Exch 5.5 server.

When you attempt to move the mail, do any of them actually move? I had a problem similar to this about a year ago. However, I don't remember the exact error message.

Anyways, the problem was with Norton Anti-Virus for exchange. We had it set for MAPI/VAPI, but we did not have it set to scan mail in the background. In other words, the mail was scanned whenever it was moved and we received an error similar to this one.

If this is the culprit, you might set it to scan in the background. You might also want to set it for VAPI only.

Hope this helps.

Check the user permissions. Faced similar error message and the .pst file was located in a folder with specific rights.

TSP

(This is from the Exchange TechMail tip, April 21, 2003)

To reduce the NDRs that your server generates from [people who] send mail to addresses in your domain for years after an employee has left the company, try creating a distribution list (in Exchange 5.5) or a distribution group (in Exchange 2000) and populate the list or group with the SMTP addresses of departed employees.

Then, the mail will have somewhere to go, so the system won't generate an NDR. And, since the messages don't goto a mailbox, they don't accumulate and take up room in the Exchange database.

Note: Before changing your mail system's behavior, however, you should think about your business and how it operates. For example, it wouldn't be very positive for your business image if customers e-mail a customer service representative and don't receive a reply. If a customer service representative no longer works for the company, it may be better to forward the mail to another representative so that the customer receives service.

You can create a distribution list (deleted users) and add the previous smtp address of that employee to the distribution list. Any mail sent to the distribution list that does not have a valid mailbox will be dropped/deleted. I realize this is management intensive, but it is the only method I have seen that reduces NDRs. I know the distribution list will grow large in your setting but only method I have seen for exchagne 5.5 .

When I know an employee is leaving, I request they remove themselves from mail lists they are on. Or I write to the site and request it myself.

When the employee leaves I delete the network account and mailbox, and create a contact in Active Directory Users container with the ex-employee's new e-mail address (be sure to add the old address as a secondary SMTP address so the Exchange server will accept the mail). This way e-mail is forwarded instead of being kept on the server, and no NDR is generated.

Most employees are grateful to have their e-mail forwarded, and most are trustworthy enough to delete any e-mail with company business that might get forwarded by mistake.

The thing is you have to do that in outlook not exchange. You need to use the micorosoft office xp resource kit to create a custom install of outlook that creates a default account useing the exchange server as it's email server and the
"%username%" variable as the account name this will autmaticly set it up to do what it is you want it to do. There are a ton of other options in office you can control useing this tool also I find it invaluable for my job.

Yes you can. There is a software called ScriptLogic which you can find at www.scriptlogic.com

It's a cool tool for administrators. You click options you need and the software generates scripts which enable you to configure almoust anything on the users desktop

It looks like a few good options have been given here.

1. Scripting: A logon script can do it.. you choose the flavor of scripting tool KIXTART is my personal fav. and there are tons of free scripts out there to use.

2. MSI modification during Office Install.. you can get the MSI tools from the MS Site, but so you know, you have to do this before you install office or even Outlook as a single component.

3. Reg Hacks.. this to me is really something that you'd want to accomplish via a logon script anyway, but it is a viable option.

Let us know what you end up doing.

Cleaswift MimeSweeper for Exchange

You can find it at:

http://www.zibiz.com/solutions/mime-sweep/MAILsweeper-for-Exchange.html

It does what you need as well as other stuff like preventing some types of attachments, preventing confidental information leaving the company, etc.

Dejan Foro
dejan.foro@inet.hr

member of Microsoft Exchange User Group Croatia
www.infodom.hr/eugcro/index.htm

Eseutil can verify the Exchange databases. You can restore the IS to a recovery server and check it there, to avoid server downtime. Also, the act of doing an online backup does a lot of checking as well. DO you have any error messgaes, events in the log etc.. when the server crashes? That could be of benefit on determining root cause.

I have been using Trend Micro Interscan Messaging Security Suite. This product is not as costly as others, comes with the AV scanner for SMTP, content filter, and spam blocker. The content filter is configurable as well.
I literaly set it up in 30 minutes and tweaked the content filter over the next 2 weeks. I immediately saw a huge difference in spam mail. It blocked about 90% of the spam, then I created or tweaked existing content filter rules to block the rest. I spend about 30 minutes per week on the entire TM AV system I have installed in my enterprise which consists of 300 users/mailboxes.
I have been extremly happy with the product and specially the cost.
Hope this helps.

We use a server in the DMZ with Praetor as the first SMTP stop. Praetor then hands the e-mail to Norton Anti-Virus for E-mail Gateways on the same server. If the mail survives all that, it then goes inside the LAN to the Exchange server. It's been working real well for us.

You can download a 30 day demo of Praetor from http://www.cmsconnect.com/

I used a product called Xwall http://www.dataenter.co.at/products/xwall.htm
It's reasonably priced, works very well, and can hand off attachment scanning to a single license anti-virus scanner, instead of paying per-seat for one that lives on the mail server. Xwall can sit on any Windows box (doesn't have to be the mail server)
Another alternative is to use Sendmail or Postfix, on a Linux box, use MailScanner/Spam Assasin, then pass the mail to Exchange when it's done.

Does anyone know of a product which will work on X.400 mail running through Exchange 5.5?

All our mail arrives via a private circuit from our HQ in Europe through x400 connectors. We are receiving tons of SPAM and my colleagues do not seem worried about that and refuse to install a filter on the SMTP gateway.

I would really appreciate any pointers to good products that work with X400.

Thanks

Paul

Does the client use a modem. I had a client with a similar problem. They had a permanent dialup account and any email with attachments would NDR with Delivery Time Expired. The messages were timing out in the Exchange queue. They were using a 33k modem and as soon as we replaced it with a 56k modem, there were no more rejections.
Just a thought.

Although this is confusing it is actually logical because after applying the service pack your installation becomes a different version than the one you used from installation media.

There are 3 possible solutions and are applicable to other Microsoft server products as well, not only Exchange.

Solution 1:
Slipstreaming. This means that you can build in your service pack into the original installation media.

1) Copy the installation files from the CD into a directory on a hard drive (for example c:\install)
2) remove archive file attributes if necesary
3) from the service pack media, use the sleapstream switch to apply the service pack to the original instalation files
This should look something like:

update.exe -s:c:\install

4) burn a new cd containing updated installation

You will have an Exchange installation media which is also usefull for new installations because you will have Exchange sp3 already incoropreated and there will be no need to install sp3 after the Exchange server installation

Solution 2 and 3: instead of strating the setup from the original media, start the setup either from add/remove programs in control panel or from the SP media because those are updated setup version which knows which files should be loaded from the sp media and which files should be loaded from service pack media

Hope this will help.

Regards,

Dejan Foro
MCP, MCP+I, MCSE NT40, MCSE+I, MCSE 2000
Zagreb, Croatia
dejan.foro@inet.hr

Hi
Have you install IIS service and ensure it start the service.Moreover,during the installation of IM you should change the status of exchange server fron INSTALL to CHANGE so that it can allow you to install.
Mail back:aderemi_solapeters_adamolekun@yahoo.com

If you are ver 2002 or > you can do it on an individual basis with rules on the client application.

If you are ver 200 or < then you can do it from the Active Directory in the properties for each user. First, you'd have to set up a generic user in Active directory, then in each user's profile properties, forward all mail to that generic user.

Set up the generic user as a profile on your station of any station where you can have outlook running all the time. In that generic user profile,create a rule for ANY incoming message to respond with a message that you create advising the domain/address information.

You'll want someone to monitor that generic user inbox and delete it's contents periodically as it will fill up fast.

Runin this manner for a period of time until you are comfortable with the thought that everyone who needs to know of the change has been informed.

I would reinforce the notification by having all of the end users send emails to their important contacts, prior to the change, stating that effective on MM/DD/YY, their email address will change to name@domain.com.

I think the easiest thing to do is just support the old address for a defined period and attach a global dislaimer (5.5 or 2000) on the end of every email leaving notifying of the change. You can run both side by side and just change default reply address's of your users.