none
Exchange Script needed to query mailbox folder permissions but exclude slashes in foldername RRS feed

  • Question

  • I have a script below that will find existing Outlook folders then get their permissions. However, if some of those folders have a forward slash in their name it won't find them because the Get mailboxfolderstatistics uses the same forward slash in the folderpath. Then to get the permission s we need to flips those forward slashes to back slashes because thats how the get-mailboxfolderpermissions interpret them. The script flips ALL foward slashes including those used in folder names.

    Is there anyway to switch ONLY forward slashes used in the folderpath, but exclude those in the foldername?

    $Mailbox = Get-mailbox user1
    Foreach ($MBX in $Mailbox) {
                    $SpecialExchangeFolders = "Top of Information Store|Recoverable Items|Deletions|Purges|Versions"
                    $FolderPaths = Get-MailboxfolderStatistics $Mailbox | where {$_.FolderPath.Contains("foldername*")
                    $ExchangeFolderPaths = $FolderPaths | % {"user1:" + $_.replace('/','\')}
                    $UsableExchangeFolderPaths = $ExchangeFolderPaths | where { $_ -notmatch $SpecialExchangeFolders }
                    $UsableExchangeFolderPaths | % {get-mailboxfolderPermission $_ } | ft Identity,User,AccessRights -AutoSize              
    }


    • Edited by ScotchTech Tuesday, October 27, 2020 1:25 AM
    Monday, October 26, 2020 2:05 PM

All replies

  • When you post code, error messages, sample data or console output format it as code, please.
    How to Use the Code Feature in a TechNet Forum Post  You can go back, edit your post and fix the formatting - you don't have to create a new one.

    And you could add some sample paths as well. (formatted as code ;-)  )

    Thanks in advance.


    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''

    Monday, October 26, 2020 3:43 PM
  • You don't have to flip anything.  The system knows how to interpret both.

    You do not need to do any of this to get just one user.  You can also just get the permissions directly from the user mailbox.

    I recommend that you post this kind of request to the correct Microsoft Q&A forum as they will help you understand how to use these commands in a hybrid environment.  The newer modules do not require this old approach and, as far as I know, haven't needed this for a long time.


    \_(ツ)_/

    Monday, October 26, 2020 3:55 PM
  • disregard the user, this was done for testing. I would be performing this on about 11K users.

    The script above works fine for gathering permissions. What I don't know how to do is exclude switching the slash if it is in the name of the folder, not the slash the separates the folder path subfolders.

    thanks

    Tuesday, October 27, 2020 1:28 AM
  • A folder name cannot contain a slash.  The slashes can only be used to separate names.


    \_(ツ)_/

    Tuesday, October 27, 2020 2:59 AM
  • I appreciate the info. However you can name an outlook folder with a slash, that's why i've been using this script for many years. Exchange sees it as a box with a question mark inside. 
    Tuesday, October 27, 2020 12:47 PM
  • Because you can does not me you should and Microwsoft says don't do this.

    I see no reason why "replace won't work.

    '/\/\/\' -replace '/','X'


    \_(ツ)_/

    Tuesday, October 27, 2020 9:32 PM
  • thank you jrv. I'm aware it's best not to name folders with slashes, but users have been doing this for 30 + years and we don't expect them to rename them. I have pushed people not to do this. However, this does not change the fact that I still need to run this script and exclude slashes within the folder name. 

    Any ideas?

    Thursday, October 29, 2020 1:36 PM
  • Any ideas?

    In my very first answer I asked you for sample paths. ;-)


    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''

    • Edited by BOfH-666 Thursday, October 29, 2020 2:57 PM
    Thursday, October 29, 2020 2:56 PM
  • sure

    folderstatistics will look like this:   /Inbox/subfolder

    to get folderpermissions we need to flip the path slashes and will look like this:  username:\Inbox\subfolder

    However if any of the folders have a forward slash in the name; i.e. test/100

    after the cmdlet runs to flip it, it would looks something like:  username:\Inbox\test\100


    when we want it to look like: username:\Inbox\test/100

    Thursday, October 29, 2020 4:09 PM
  • I asked you to format it as code and I asked for sample pathS!!!  ... plural. And I'd expect samples to contain the before and the after.  :-/

    If it's about replacing only the last backslash with a slash you can do this:

    'username:\Inbox\test\100' -replace '\\(?=[^\\]+$)', '/'


    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''


    • Edited by BOfH-666 Thursday, October 29, 2020 6:56 PM
    • Proposed as answer by jrv Thursday, October 29, 2020 8:28 PM
    Thursday, October 29, 2020 6:54 PM
  • As I noted above.  Path separators are not allowed in any names in any Microsoft products and bot "/" and "\" are path separators.  Before Exchange Online the "/" was allowed but recommended against.  Now that it is an supported to allow the use of Unix paths it is disallowed in mailbox names.  Using it will create issues going forwards.

    The safest way to fix this mistake is to retrieve the object name without the path and then construct the path after flipping the character.  Even this will run into issues depending on what you are trying to do.

    In all cases MS constantly states that these characters should not be allowed in any object name in any subsystem.

    The main problem with using BOfH-666 solution is that there is no way to know if the last backslash is part of the name or the path.  Extracting the name and converting is the only safe way to do this in code.


    \_(ツ)_/

    • Proposed as answer by BOfH-666 Friday, October 30, 2020 12:01 AM
    Thursday, October 29, 2020 8:52 PM
  • The problem with "was allowed but recommended against" is that mailbox folder names (and public folder names) are created by users, not admins.

    Even admins, designers, and developers often chose to overlook "recommendations". Witness the awful, awful, decision of many early adopters of Active Directory to choose "single label" domain names! The JDP Joint Development Program) members and guiding committee(s) never had the backbone to say "do not do this!". I know, because I was participant in the JDP after joining my company's IT department and they'd already chosen a single-label root domain for their forest.

    I can sympathize with the OP's problem as I too had to continually deal with the "slash problem" in Exchange mailbox and public folder names. Correcting those folder names was a painful process using MFCMapi. :-(


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Thursday, October 29, 2020 9:28 PM
  • Yes.  The issue is also deep in the computer industry and I. too, have been fighting against the trivial choices that always seemed to be available.  

    Remember Y2K?  I argued against short dates decades before because they remove critical identifying information. Unfortunately the programmers and vendors chose "cheap" over "correct" due to the cost of storage.  In technology compromise without a narrow scope is deadly.  We have seen this throughout history and yet we fail to address this issue.  Climate change was first noted around 1860 and yet no one reacted.

    Users cannot easily create folders that are incorrectly built from bad characters.  We can set rules and use the API to prevent this.  We should do that.

    I always prefer to fix things at the root as it makes the future more predictable and better behaved.

    Again --- the replacement algorithm work but only under a narrow set of circumstances.  It has the same chance of breaming things as it does fixing them.  More code and a logical test scenario can remedy this.


    \_(ツ)_/

    Friday, October 30, 2020 2:14 AM
  • thank you both. I guess if there is no way to detect if the slash is in the name rather than the path, then there is no way to exclude it.

    Is this correct?

    If yes, than I agree, the best option would be to rename the folder. I would obviously have to explain this to the end-user first.

    Thanks again.

    Friday, October 30, 2020 2:44 PM
  • I'm relying only on my memory here, so don't take this a gospel. IIRC, the folders have a property named "DisplayName" that shouldn't include the path to the folder. You may be able to use that to remove the name of the folder from the folderpath, replace the offending slashes, and then reconstitute the folderpath by adding the original display name to it. Now, whether that display name will be the name of the folder in the folderpath I can't say. I don't recall if the user changes the folders name it changes only the display name or the path or both.

    It's been almost six years since I've touched an Exchange server (you'd think I'd remember from working on Exchange since it was in pre-release!). Base your confidence in this reply on that!


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Friday, October 30, 2020 7:38 PM