Hi,

I just discovered a bug in solution for Hosted Exchange.

As soon as first business user was created with Premium Plus Mail plan, ALL other user within the same business organization able to use Outlook 2003 to connect to Exchange server.

It looks like users can't use Outlook 2003 just because there is no available Address list to create Outlook profile. MPS creates Address lists for business organization during creation first user with plan like Premium Plus Mail (any plan with option <showInAddressLists/>). And all this ALs have permissions like AllUsers@business_org_name – Read.

Do you have any solution to fix this problem?


Dmitri Gaikovoi

Softcom Technology Consulting Inc.

I don't have that problem so probably it has something to do with your security settings.
You can better check that first.

Martijn Bakx

It is not about "my" security settings. It's behaviour by design.

Steps to reproduce the problem:

1. Create Business organization using http://www.consolidatedmessenger.com/HeWebClient/home.aspx (all links and references from “Solution for Windows-based Hosting with Hosted Exchange 2003). Make sure Gold Mail and Platinum Plus Mail plans available for this organization.
2. Create Business user (Gold User) in this organization with Gold Mail plan
3. Configure the Outlook 2003 for Gold User. Use manual process or http://consolidatedmessanger.com/RpcHttpConfig
4. Outlook will be unable to resolve mailbox and server names and create MAPI profile with error “Bookmark is invalid”.
5. Create another user in the same organization with Platinum Plus Mail plan.
6. Start Outlook 2003. Type proper user name and password for Gold User. Outlook will create MAPI profile for Gold User and user can use now rich client.

Dmitri Gaikovoi

Softcom Technology Consulting Inc.

The answer I got back from the product team is that this is by design. The way it is supposed to work is that even though a non-platinum user can access mail with outlook they do not have access to the address book or the offline address book which will sufficiently hamper the use of outlook by that user.

Does this make sense? Is this your experience as well?

Thanks

No. The problem is exactly in access to organization AL for non-platinum users. I checked permissions on ALs created by MPS, and it looks like AllUsers@business_org_name – Read, Open Address List.

Yesterday I received response from Microsoft Canada about this issue:

“This is not a bug, this is the way that Exchange and ALs work. We wait to create an AL for a hosted organization until there is at least one MAPI-enabled user in an org - until you have the first MAPI user, that means that no one can access via MAPI since they can't set up a profile.

However, once the first MAPI user is created, we then have to go back and create the AL with all other users in that organization - otherwise the user who has MAPI will not be able to do lookups of other users in their org.

The downside of this is that any user in the org, at that point, can use MAPI if they are smart enough to know their mailbox location and use profile manager to create a profile. We don't give non-MAPI-enabled users access to the AL or OAB for that org - you have to be a member of MAPIUsers group for that org to have access to the ALs. This is certainly not optimal, but it's the best we can do right now.

The Exchange team has committed to add the ability to enable/diable MAPI access on a per user basis by adding flags to the msExchProtocolSettings attribute on the user for SP2 - then we will be able to control MAPI access on a very granular basis.

Until then, this is the best that can be done.”

"MAPIUsers group for that org" - What is this? I didn't find any references to this group in current version of the Microsoft solution for Hosted Exchange.

Thanks.

Dmitri Gaikovoi

Softcom Technology Consulting Inc.

Phone: (416) 957-7436

I believe the mapiusers group is used by the provisioning engine to limit access to the AL and OAB. This is not a group you would manually configure.

“MAPIUsers” group is not exists anywhere in Active Directory. And I don’t see anything similar that should do control over MAPI access.

Ones again – Microsoft Solutions for Windows-based Hosting including Hosted Exchange 2003 (March 2004) unable to control this future efficiently.

Thanks,

Dmitri Gaikovoi

Softcom Technology Consulting Inc.

Greetings,

Seems like this issue is fixed in "Microsoft® Solution for Hosted Messaging and Collaboration v3.0".

Just one final question to Microsoft:

Was it so difficult to say that you are going to implement this feature in HE v3?

:-(

Regards,

Dmitri

Hi,
I can confirm that this issue is resolved in HE3. HE3 MPS creates an OutlookUsers@domain.com security group for the customer OU, and the GAL permissions are set against this group.
I understand this will be further reinforced by E12. Remember that HE is a way to deploy Exchange which was designed for the enterprise. As HE gets more presence, more HE type features will go into the core product.

Also remember that HE3 was only RTM recently, and until RTM they can't categorically say "this will be fixed". Having worked with a lot of betas and early programs, features that don't make the grade get cut. My point is that they have only recently been able to say this, and HE3 is only now getting marketing attention.

My $0.02. Any q's - please ask.

Enomagic.

Hello,

In fact I fixed this problem by myself ;-)

In this specific scenario (Hosted Exchange 2003) I use NTFS permission for file %SYSTEMROOT%\system32\rpcproxy\rpcproxy.dll on front-end servers to control who can use Outlook 2003 (RPC over HTTP actually). I created MAPIDisabled group in domain and revoked Read access from this group on rpcproxy.dll. I put all users who shouldn’t use Outlook 2003 into MAPIDisabled group (and remove when it necessary).

I think, it is more effective, because it requires less user groups in AD and less ACL manipulations in Exchange. Plus it should be faster since back-end servers are not involved in user rights control.

Regards,

Dmitri Gaikovoi

Hello,
that is an interesting work around.

But basically you are introducing a level of user management you have to specifically cater for. The group that you give permission to that .dll will have to have every MAPI user in it - which means you have to manage membership of that group. Whether you use nested groups or just the actual users - you'll have to cater for this for every provisioined Hosted Exchange user.

That is the only issue I see with that approach, but since a solution is provided in HE3 by MPS and managed by MPS, you could be re-inventing the wheel.

Let me know how it goes. Wonder if you could do something similarly with the MAPI publishing rule in ISA.....hmm....

Ben

Hi,

Yes, I manage group membership by myself ;-). It is not so complicated (just 10-15 lines of code).

Unfortunately, I can't say anything about ISA because we are not going to use it.

Dmitri