Carl C's questions

I am running Exchange 2010 and 2003 in coexistence, and recently switched to using Exchange 2010 as my OWA server. User mailboxes are still on 2003.

Almost everything works fine, except that when users click the "Log Off" button in OWA 2003, they get a 404 error. Exchange 2010 OWA users have no problem logging off.

Exch 10 CAS: mail.company.com (This is an NLB, if it matters). Exch 2003 Front End: legacy.company.com

Outlook Web Access/App works fine for both 2003 and 2010 users. Users can successfully login and view their mailboxes on the legacy 2003 side through the 2010 CAS. I don't have any certificate errors.

• The 2003 OWA log Off button has the following URL: https://legacy.company.com/exchange/mailboxname/?Cmd=logoff
• When I click the log off button in legacy 2003 OWA, I am redirected to the following URL and a 404 not found error: https://mail.company.com/exchweb/bin/auth/owalogon.asp?url=https://mail.company.com/exchange/&reason=1

The mail URL refers to Exchange 2010, which uses a Virtual Directory to /owa for /exchweb. There is no /bin/auth/owalogon.asp file in the Exchange 2010 directory structure. That file/directory structure DOES exist on the 2003 side, but the log off button redirects to mail, not to legacy I tried copying the 2003 /bin/auth directory over to 2010, but that didn't work.

Has anyone seen this behavior? Are your OWA 2003 log off URLs different? Any idea if I can customize the logoff command in Exchange 2003 to forward to a working log off page? Any other ideas on how to address the issue? My searches have turned up nothing.

I am new to DFS and need to rename an existing DFS root (OldDFS$) to a new name (NewDFS$) so that it's clearer to its users. This is on an AD domain and there is no replication of the DFS data. The current DFS root points to a Domain Controller (DC1) running Windows Server 2003 R2. The actual data (links, targets?) is on another server (Server1). The data in those links (targets?) can stay in place on the same server and drives. I just want the DFS root to have a new name. I really don't want to lose any data or have to replicate it, as there is 200 GB of data in the DFS folders.

What I want to do:

Change DFS name \\domain.com\OldDFS$

To DFS name \\domain.com\NewDFS$

My current DFS root target is: \\DC1\OldDFS$

I have three links (or are these targets?) under the current root, none of which needs to change:

\\server1\link1$
\\server1\link2$
\\server1\link3$

How do I go about this?

I'm working on deploying Exchange 2007 into an existing Exchange 2003 environment. Microsoft does not support placing an Exchange 2007 Client Access Server (CAS) in a perimeter/DMZ network. Microsoft instead suggests placing an ISA Server in the perimeter/DMZ network and using it to reverse proxy requests to the CAS server.

What is the advantage of using the ISA server as a reverse proxy compared to forwarding port 443 from the external network through the perimeter/DMZ to the CAS server on the internal network? Will I have SSL certificate issues if I forward the port? Are there other ports that need forwarding?

Update: I found the following two advantages here:

When you publish an application through ISA Server, you are protecting the server from direct external access because the name and IP address of the server are not accessible to the user. The user accesses the ISA Server computer, which then forwards the request to the server according to the conditions of the server publishing rule.

SSL bridging protects against attacks that are hidden in SSL-encrypted connections. For SSL-enabled Web applications, after receiving the client's request, ISA Server decrypts it, inspects it, and terminates the SSL connection with the client computer. The Web publishing rules determine how ISA Server communicates the request for the object to the published Web server. If the secure Web publishing rule is configured to forward the request using Secure HTTP (HTTPS), ISA Server initiates a new SSL connection with the published server. Because the ISA Server computer is now an SSL client, it requires that the published Web server responds with a server-side certificate.

Adding a second part to the question, are these justification for purchasing a second server, licensing, setup, troubleshooting, etc. How have you done this in your environment, especially in small (<200 users) environments?

One of our users is currently overseas, and her Active Directory domain password expired. She's logging on with a laptop using cached credentials and (non-AD integrated) VPN, but she can't logon to file shares or Outlook with the expired password. If I change the password, I'm concerned it's going to create cached logon problems for her with the laptop, which I won't be able to fix while she's eight time zones away. The flag that says she must change her password is already set. If I set her password to never expire, will that prevent her from having to change the password, or must she change it no matter what I do?

A similar question here indicates that setting the account to Never Expire would work, but I'd like some confirmation.

Edit: The password never expire setting would only be in place until she returns to the office. I'm just trying to allow her back into the system while she's away, without making the problem worse.

Final edit: Setting the "Never expire" flag fixed the problem. The user will keep her existing password until she returns next week.