microsoft / emat Goto Github PK

We have Exchange 2010 and are preparing to go hybrid with O365/Exchange Online. I've been testing out this tool and so far I am very encouraged.

I have noticed that during the folder enumeration step I get a lot of errors along the lines of:

The operation couldn't be performed because '[email protected]:\Top of Information Store' couldn't be found.
+ CategoryInfo : NotSpecified: (:) [Get-MailboxFolderPermission], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : 9C944E08,Microsoft.Exchange.Management.StoreTasks.GetMailboxFolderPermission
+ PSComputerName : ourcashubserver.ourdomain.local

In addition to the "Top of Information Store" errors I also see ones for Versions, Purges, Deletions, Recoverable Items, and a variety of user-created folders with what I am guessing are characters the script couldn't handle...likely in the enumeration step using Get-MailboxFolderStatistics.

I'm not worried about delegated permissions on deleted item folders. It might be nice to be able to better enumerate the user-created folders if a way can be found to handle the characters (I'm guessing slashes are particularly problematic here).

That said, it seems very reasonable to want permissions for the top level, which I think could be included by doing something like:

$utente = $folders | %{ Get-MailboxFolderPermission $($alias+":"+$_).Replace(":\Top of Information Store","") | select Identity,User,Accessrights,foldername}

After switching from our test environment to production with the tool, I'm now looking at over 6000 mailboxes (maybe 1700 of which we will likely purge before migrating to O365). Unfortunately, I've got a persistent bundle of a different ~1700 mailboxes that all end up in the same migration group and I have had difficulty getting them broken apart. I tried adding the mailboxes that we will eventually purge to the blacklist (by email address as exported to outputs.csv) as well as mailboxes that had a large number of relationships in the stats output file in order to break up the large group into smaller ones, but with little change in the output.

It appears 400-500 of the mailboxes on the blacklist still appear in the outputs.csv file, almost all of them in the one big group, and I'm having a hard time coming up with something they have in common that might explain it.

I have found that blacklist.csv is apparently case-sensitive, meaning that I have to add duplicate lines like
DOMAIN\svaccount
DOMAIN\svAccount
[email protected]
[email protected]

Is there a limit on how many entries can go into blacklist.csv, or characters/formats that are not allowed?

Does anyone have suggestions as to how best to break apart larger groups, and how to format the blacklist file to properly exclude accounts that might be gluing everyone together?

Thank you for your help. This is an amazingly complex analysis task.
Chris

Group Expansion is not working

If identity of the mailbox or displayname cointains "comma", the split function do not work correctly causing exception (Index out of range)

I'm looking at the Permissions_aftergroupexpansion.csv file and I'm seeing Identity and User values that contain commas and they aren't contained in quotes. I am concerned that the Calculate executable is not then able to parse that data correctly when generating subsequent output files since a split on the comma character would result in more than three fields. I'm starting to suspect that is why I have so many users getting lumped into one giant group.

It looks like there was previously an issue fixed in RC1 regarding data with commas, but it wasn't clear to me which step in the process that referred to. The CSV files generated by ExportScript.ps1 have all relevant fields contained in quotes, so I suspect that's what was referred to.

It seem that mail address with / in personal part make program to crash. I've tested 3 times on 2 Machines but it stops at same Place.

Edit: It seems to be something else bacuse changing address to - instead of / doesn't made any difference

trace.zip

The readme states that folder permissions and send on behalf aren't exported, but clearly the script appears to be making the attempt. I previously reported an issue with the folder permissions that was labeled a bug, so I thought I'd share what I found with send-on-behalf in case it is helpful.

In the SnB.csv file, I was seeing lines that look like this:

"domain.local/TopOU/SubOU/userCN","System.Collections.ArrayList","SNB",,

I assume the calculation is not aided by the name of the .NET class for the property extracted. It looks like the script is attempting to produce a semicolon-delimited list inside the row of the CSV file containing the users with that permission granted. If that is the goal, I found this line works better:

import-csv mailboxes.csv | get-mailbox | ?{$_.GrantSendOnBehalfTo} | select Identity,@{Name='User';Expression={$_.GrantSendOnBehalfTo -join ";"}},@{Name='AccessRight';Expression={"SNB"}},ExtendedRight,FolderPath | export-csv SnB.csv -encoding "unicode" -NoTypeInformation

The result is something along the lines of:
"domain.local/TopOU/SubOU/userCN","domain.local/TopOU/SubOU/otheruserCN;domain.local/TopOU/SubOU/anotheruserCN;domain.local/TopOU/SubOU/yetanotheruserCN","SNB",,

Of course our OUs and object names have spaces, so I don't know how well the calculation tool is making use of the data, but to my knowledge there are no semicolons in the AD data to complicate things further.

Chris