locked
Can't view user's calendar permissions; his team can't view his calendar RRS feed

  • Question

  • In our Exchange Server 2007 SP1 environment (plus latest Update Rollup), we have a user who has set up his calendar permissions in what appears to be a perfectly good way, giving his teammates Reviewer access to it.  However, his teammates can't view his calendar--it's blank to them.  When I say that his permissions look fine, I mean that the screen shot of his calendar permissions that he e-mailed to me looks perfectly reasonable.  I can't view them myself from Outlook as I would expect to be able to.

    When I, an all-powerful Exchange Org Admin with explicitly-set Full Access permissions on his mailbox, open his mailbox from Outlook 2007 (via a separate mail profile) and try to view his Calendar Permissions, I get an error message pop-up:

          Some permissions cannot be displayed.  The client operation failed.

    I can open other mailboxes of users in the same OU of Active Directory (inheriting the same permissions) and view/adjust their calendar permissions.  I use this operation routinely for shared calendars and have never had trouble viewing permissions.

    Help?  I've tried moving his mailbox to another database, in the hope that some subtle database corruption would be corrected, but that didn't help.

    Suggestions would be very much appreciated.  Thanks!

    Wednesday, May 6, 2009 10:11 PM

Answers

  • Hi,

     

    Please understand that the PFDavAdmin tool use WebDav to enumerate public folders/mailboxes in the /ExAdmin virtual directory using SEARCH method. The ExAdmin Virtual directory is created on the mailbox server role.

     

    For your reference:

     

    Default settings for Exchange-related virtual directories in Exchange Server 2007

    http://msexchangeteam.com/archive/2008/02/01/447989.aspx

     

    Therefore, when using PFDavAdmin tool, you need to point to mailbox server role instead of CAS server.

     

    In addition, regarding the error:

     

    "Could not expand https://exchange.my.domain/exadmin/admin/my.domain/mbx/user@my.domain/non_ipm_subtree/: The underlying connection was closed: Unable to connect to the remote server."

     

    I suggest you run the PFDavAdmin tool on the Active Cluster Mailbox Node to test the issue in order to bypass network issue to connect to exadmin virtual directory on the mailbox server.

     

    In addition, you can check the IIS log on the Active Cluster Mailbox Node for further information.

     

    Mike

    • Marked as answer by Mike Shen Thursday, May 21, 2009 10:07 AM
    Friday, May 8, 2009 10:08 AM
  • Hi,

     

    Thanks for your response.

     

    The (403) Forbidden may occur if the IP Address of the client which runs PFDavAdmins tool is rejected by the ExAdmin virtual directory. Therefore, I suggest you check the IP Address and Domain Name Restrictions setting of ExAdmin Virtual Directory in IIS.

     

    In addition, please check the IIS log and post the related log here for further check. We need to check the sc-substatus for further information


    Mike

    • Marked as answer by Mike Shen Thursday, May 21, 2009 10:07 AM
    Monday, May 11, 2009 7:12 AM
  • First of all, my apologies for not getting back to this thread.

    Answer to original question:

    PFDavAdmin noted in the DACL state that the permissions on the user's calendar were not in canonical form.  Checking the "Force canonical order and valid masks" box and commiting changes fixed the user's problems.

    Getting PFDavAdmin to run in the first place:

    It turns out that our Mailbox cluster did *not* have the /ExAdmin virtual directory present.  I think that a previous Exchange admin had gotten rid of a bunch of virtual directories while having difficulty with a third-party AV product, which included a web interface; lots of uninstall/reinstall happened.

    I recreated the /ExAdmin directory, installed PFDavAdmin on a computer on the same subnet (to avoid the router's firewall), and I no longer had any trouble with PFDavAdmin.

    /ExAdmin and /Exchange (and others) must exist on the Mailbox server, right?

    In case it helps with future questions, it's worth noting that unless you use features (e.g., Outlook Anywhere) and/or tools (e.g., PFDavAdmin) that require web apps, a web server isn't really a necessity on a server that holds only the Mailbox role.   I think the only reason we *did* have the web server up was for the administrative console of the 3rd-party AV app.  Then, when we decided to add Outlook Anywhere, we discovered that /Exchange was necessary.  (That took some time and investigation.)  And now, for PFDavAdmin, /ExAdmin is necessary.

    People in an environment that really tries (perhaps too hard) to go by the principle of "do not run unnecessary services" might be inclined to just disable IIS on the mailbox server--they don't necessarily need it.  They, like us, might have trouble down the road, but that's often the cost of not keeping everything in the default state.

    Thank you!

    Thanks *very* much to Mike and Amit for your patient attention and helpful comments.

    And to Ilantz, your solution of export/delete/create/import was certainly the "right" solution in isolation.  In my particular case, I really wanted to make PFDavAdmin work, and I'm glad that I took the time to do it.  It's been helpful in other situations, particularly in examining permissions on users' calendars.


    • Marked as answer by Mike Shen Friday, June 12, 2009 1:04 AM
    Thursday, June 11, 2009 5:24 PM

All replies

  • Next step I would try fixing calendar folder permission by opening his mailbox with PFDavAdmin. 

    Make sure that you have .Net Framework 1.1 installed on the workstation (yes workstation or any other server, don't install .net 1.1 on Exchange 2007 server) where you open mailboxes with PFDavAdmin in order to make it work correctly, right-click on his calendar folder, click on "Fix folder DACLs", try to give permission there and check the situation...

    Amit Tank | MVP - Exchange | MCITP:EMA MCSA:M | http://ExchangeShare.WordPress.com
    Thursday, May 7, 2009 4:29 AM
  • Amit,

    I was afraid you'd say that.  :-)  I promise to look for more information on PFDavAdmin if the questions I have are too obvious, but I my searching hasn't yielded any answers so far.  In particular, what does PFDavAdmin want in the "Exchange Server" textbox?

    If I point PFDavAdmin at our CAS service (OWA.my.domain, a pair of servers using NLB) and select the "All Mailboxes" radio button, I get:

    "Could not expand https://owa.my.domain/exchange/: Object reference not set to an instance of an object"

    If I point PFDavAdmin at our clustered Mailbox server (exchange.my.domain, a different pair of servers running Windows Cluster Services), I get the full listing of mailboxes, but if I try to open one, I get:

    "Could not expand https://exchange.my.domain/exadmin/admin/my.domain/mbx/user@my.domain/non_ipm_subtree/: The underlying connection was closed: Unable to connect to the remote server."

    Given that we have our CAS and mailbox functions separated, is it possible that PFDavAdmin is looking for a web service that doesn't exist on our Mailbox server that doesn't have full CAS functionality?  (Or if I talk to the CAS service, does it need more specific information to proxy the request to the mailbox server?)  I don't see an "exadmin" app on the mailbox server, and my understanding is that a mailbox server wouldn't necessarily run any web services at all.  We had to set up the "exchange" web app on the Mailbox server in order to get Outlook Anywhere to work, but that's the only web app on the mailbox server, as far as I can tell.

    Thank you!

    Thursday, May 7, 2009 10:36 AM
  • Actually you need to point the clustered mailbox server name (not even node computer names). It doesn't require CAS server to connect. You can refer Jame's first response in below thread....


    Amit Tank | MVP - Exchange | MCITP:EMA MCSA:M | http://ExchangeShare.WordPress.com
    Thursday, May 7, 2009 10:45 AM
  • Hi,

     

    Please understand that the PFDavAdmin tool use WebDav to enumerate public folders/mailboxes in the /ExAdmin virtual directory using SEARCH method. The ExAdmin Virtual directory is created on the mailbox server role.

     

    For your reference:

     

    Default settings for Exchange-related virtual directories in Exchange Server 2007

    http://msexchangeteam.com/archive/2008/02/01/447989.aspx

     

    Therefore, when using PFDavAdmin tool, you need to point to mailbox server role instead of CAS server.

     

    In addition, regarding the error:

     

    "Could not expand https://exchange.my.domain/exadmin/admin/my.domain/mbx/user@my.domain/non_ipm_subtree/: The underlying connection was closed: Unable to connect to the remote server."

     

    I suggest you run the PFDavAdmin tool on the Active Cluster Mailbox Node to test the issue in order to bypass network issue to connect to exadmin virtual directory on the mailbox server.

     

    In addition, you can check the IIS log on the Active Cluster Mailbox Node for further information.

     

    Mike

    • Marked as answer by Mike Shen Thursday, May 21, 2009 10:07 AM
    Friday, May 8, 2009 10:08 AM
  • Hi,

    excuse me for the "radical" approach , but I tend to measure my need actions and the effected users.. if this is a single case , and this user mailbox could be recreated I'd rather do that instead .

    don't get me wrong there are cases when you take your powertools and start drilling , should this case be one ?
    exchange 2007 can allow you to rather quickly do that with export-mailbox.

    "Tip" - write down that users legacyExchangeDN value. if it will different when you'll re-create the mailbox you'll need it to avoid NDR & issues.

    good luck
    MCSA Messaging
    Friday, May 8, 2009 7:01 PM
  • Mike & Amit,

    OK, now I'm on to something.  The first problem was just stupidity on my part--the mailbox server is on a different subnet, and a network firewall was blocking access--we never need to connect to TCP 80/443 on the mailbox server from client nets.  (CAS, yes.  Mailbox, no.)  It confused me that mailbox names got retrieved successfully, but I assume that they're retrieved from the GC, not the mailbox server.

    I moved the test to the same subnet. The error message when trying to open a particular mailbox is now different:

           Could not expand http://exchange.my.domain/exadmin/admin/MY.DOMAIN/mbx/whoever@my.domain/non_ipm_subtree/
           The remote server returned an error: (403) Forbidden

    I know that when I set up Outlook Anywhere, which enables limited RPC proxy from the CAS servers, I think I made some recommended changes on the mailbox server to prevent arbitrary RPC proxying.  Maybe those restrictions are breaking WebDAV access from the other computer that I'm using--the mailbox server probably isn't expecting WebDAV from anybody but the CAS servers.  I'll revisit those configuration changes, unless the error seems to indicate something simpler.

    Any other suggestions are welcome.

    I'm running this as a domain admin with Exchange Org Administrator rights and Full Access permissions on the particular mailbox I'm trying to open.

    Thanks.

    Friday, May 8, 2009 7:29 PM
  • Hi,

     

    Thanks for your response.

     

    The (403) Forbidden may occur if the IP Address of the client which runs PFDavAdmins tool is rejected by the ExAdmin virtual directory. Therefore, I suggest you check the IP Address and Domain Name Restrictions setting of ExAdmin Virtual Directory in IIS.

     

    In addition, please check the IIS log and post the related log here for further check. We need to check the sc-substatus for further information


    Mike

    • Marked as answer by Mike Shen Thursday, May 21, 2009 10:07 AM
    Monday, May 11, 2009 7:12 AM
  • Hi,

    Any update regarding the issue?

    Mike
    Friday, May 15, 2009 6:43 AM
  • First of all, my apologies for not getting back to this thread.

    Answer to original question:

    PFDavAdmin noted in the DACL state that the permissions on the user's calendar were not in canonical form.  Checking the "Force canonical order and valid masks" box and commiting changes fixed the user's problems.

    Getting PFDavAdmin to run in the first place:

    It turns out that our Mailbox cluster did *not* have the /ExAdmin virtual directory present.  I think that a previous Exchange admin had gotten rid of a bunch of virtual directories while having difficulty with a third-party AV product, which included a web interface; lots of uninstall/reinstall happened.

    I recreated the /ExAdmin directory, installed PFDavAdmin on a computer on the same subnet (to avoid the router's firewall), and I no longer had any trouble with PFDavAdmin.

    /ExAdmin and /Exchange (and others) must exist on the Mailbox server, right?

    In case it helps with future questions, it's worth noting that unless you use features (e.g., Outlook Anywhere) and/or tools (e.g., PFDavAdmin) that require web apps, a web server isn't really a necessity on a server that holds only the Mailbox role.   I think the only reason we *did* have the web server up was for the administrative console of the 3rd-party AV app.  Then, when we decided to add Outlook Anywhere, we discovered that /Exchange was necessary.  (That took some time and investigation.)  And now, for PFDavAdmin, /ExAdmin is necessary.

    People in an environment that really tries (perhaps too hard) to go by the principle of "do not run unnecessary services" might be inclined to just disable IIS on the mailbox server--they don't necessarily need it.  They, like us, might have trouble down the road, but that's often the cost of not keeping everything in the default state.

    Thank you!

    Thanks *very* much to Mike and Amit for your patient attention and helpful comments.

    And to Ilantz, your solution of export/delete/create/import was certainly the "right" solution in isolation.  In my particular case, I really wanted to make PFDavAdmin work, and I'm glad that I took the time to do it.  It's been helpful in other situations, particularly in examining permissions on users' calendars.


    • Marked as answer by Mike Shen Friday, June 12, 2009 1:04 AM
    Thursday, June 11, 2009 5:24 PM
  • Great job ! Thanks for updating us :)
    Thursday, June 11, 2009 6:27 PM
  • Hi,

    Thanks for your response and sharing your solution here.

    Mike
    Friday, June 12, 2009 1:09 AM