Hi,

As some of you are aware, recently did an upgrade to Exchange2000.

The problem we are having is that when clients go to delegates, and adds in a user, say joe bloggs full access to calendar/tasks, they click ok.

However, when they then go back in it, the permissions are set to none - thus no access.

It doesn't matter if the clients are using outlook 97/outlook2k or outlookxp - same thing happens. This is I believe must be down to permissions, but which one?

I can do a manual permissions on the server (going to advance view in ad users and computers) but I do not want to do this, as it also gives access to inbox etc...

Any ideas on how to fix the problem??

 

I hate permissions [img]images/smilies/mad.gif[/img]

Any chance that there are bits of the old GAL still kicking about? I'm thinking that perhaps the old accounts are given permissions and when it's found that they no longer exist, they get zapped. (A wild and dangerous thought )

Does Microsoft or Google Groups have anything useful to say?

 

you didnt do exchange 2000 as part of your mcse??

David

 

david -> nope- on a course in october though!

not sure if it is to do with permissions though, I used the migration wizard in the end to transfer mail accross.

 

When I wanted to migrate from notes -> exchange 5.0 I just told them to print the emails they wanted to keep (25 Users)....

I was young then!

David

 

lol - that still doesn't solve this

in oulook, you go to tools -> options -> delegates (tab)

then you can add in people who you want to have access say to your inbox etc - they can add users, assign the relevant permissions, however, after they have clicked ok, and then gone back into it, it resets back to none.

Didnt have this problem in exchange5.5! so any ideas?

 

couldnt really find anything... other than to do with disabling schedule + as primary calendar... and

XADM: Move Server Wizard Does Not Update Mailbox Folder Permissions
The information in this article applies to:
Microsoft Exchange Server 5.5 SP2, 5.5 SP3

Symptoms
After you run the Move Server Wizard, mailbox folder permissions and delegate access may no longer function properly.
Cause
This issue can occur because the Move Server Wizard does not attempt to update folder access or delegate access, other than to make sure that the mailbox owner can gain access to his or her mailbox after the move.
Workaround
To work around this issue, re-establish any delegate access or permissions that were lost when you ran the Move Server Wizard by re-applying the settings from the client.

If you use the Mailbox Information Program (MBInfo) version 2.01 or later, you can create a comma-separated values (CSV) file that contains folder permissions for most of the folders in the information store. (For information about exactly which folder permissions are exported to the file, see the documentation for MBInfo.)

When delegate access is granted, some folder permissions are usually granted as well, so the folder permission information from MBInfo should include any mailboxes that have granted delegate access to others. The output does not explicitly show the access as delegate access; the output only shows the folder permissions that are granted in conjunction with the delegate access.

The information that you extract with MBInfo provides a list of mailboxes. You can determine if permission and delegate settings are correct for these mailboxes, and if they are not, you can either re-apply the appropriate settings or notify users that they may need to re-apply these settings themselves.

You can obtain MBInfo from Microsoft Product Support Services (PSS). Microsoft PSS will use commercially reasonable efforts in addressing all support problems with MBInfo.
Status
This behavior is by design.
More Information
Folder permissions are stored as properties of a folder and are granted to a mailbox (not a Windows NT account). When you grant another mailbox permission for a folder, the Distinguished Name (DN) of the mailbox that you are granting permissions to is stored on the folder to which that mailbox will have access.

A mailbox DN is similar to the following:
/o=Organization/ou=Site/cn=Recipients/cn=MailboxDirectoryName
After you run the Move Server Wizard and change the organization or site name, mailboxes on the server that you moved have a different DN than they had before the move. This means that the mailbox DN does not match the DN that is stored on the folder, so access to the folder no longer works properly. When you remove and re-apply the permissions, you use the new mailbox DN and permissions are re-established.

The Move Server Wizard does not check all of the folders to make sure the permissions are updated. You can grant any mailbox in the organization permission for your folders. If the Move Server Wizard maintained all of the folder permissions, the Move Server Wizard would need to check the information stores of all of the servers in the organization to see if the mailboxes on the server that the Move Server Wizard was moving had permissions for any mailbox folders, and then update those permissions accordingly (which is nearly impossible to do).

In some situations, folder permissions between two mailboxes that both reside on the server that you are moving may be maintained, but this does not always happen and is not something that you should rely on.
First Published: Apr 3 2000 9:36AM
Keywords: exc55sp2 exc55sp3 kbprb pilgrim X500


David

 

Good luck..

I work within a very large investment bank as a AD specialist and have been working with the X2K security model for sometime. If I had my way we'd remove it today and stick with x55..

Permissions are an absolute dog in x2k..

Doesnt help you, but at least you may feel relieved that your not the only person that struggles with x2k

cheerio

 

ok managed to get it sorted, went manual through each exchange box and reset the permissions.

Another problem I am getting now is with groups (universal distribution lists) in exchange if try and assign permissions doesn't work, for delegates or assigning permissions to public folders - is this meant to do this?

 

DL's cannot have perms assigned to them, you need to use security groups.

You'd need to create equiv USG's and perm with these against your public folders.

[Edited by Ga22ar - 7/31/2002 12:39:18 PM]

 

gazza can u drop me an email with your number - wouldn't mind asking u a few q's..

(if that is ok)