Dan's Office 365 Page

Want to List Office 365 Mailbox Permissions?

Dan-O365 — Fri, 26 Apr 2013 00:48:00 GMT

Hello Everyone-

Let’s say you want to get mailbox permissions on a cloud mailbox- easy enough right? Well- when you look at the user you will see it is actually the samaccount name in O365- which has a partial section of the name and then a bunch of numbers. Not really useful. You can take this user and run get-user “samaccountname” and get the actual identity. But how do you get all that in one csv or get a list of all mailbox permissions?

I was messing around with this since someone asked me if it was possible.. and here is what I came up with.

$dan=get-mailboxpermission “dan”

$dan | select-object accessrights,user,@{Name="userprincipalname";Expression={get-user$_.user }} |Export-Csv c:\temp\test4.csv –notypeinformation

The report will look like this: ** so we ADD the 3rd column after we perform a lookup for the value

AccessRights	User	userprincipalname
FullAccess, ReadPermission	NT AUTHORITY\SELF
FullAccess	NAMPR04A001\Deleg50549-408661602	Delegate2
FullAccess	NAMPR04A001\dante50549-335097617	dantest3

What if you have a lot of mailboxes you want to find out about?

Here is a good option as well..

$dan=get-mailbox|get-mailboxpermission

$dan | select-object identity,accessrights,user,@{Name="userprincipalname";Expression={get-user $_.user }} |Export-Csv c:\temp\test5.csv –notypeinformation

The report will look like this now: (Including identity to indicate what mailbox we get permissions for)

Identity	AccessRights	User	userprincipalname
activesynctest1	FullAccess, ReadPermission	NT AUTHORITY\SELF
dan	FullAccess, ReadPermission	NT AUTHORITY\SELF
dan	FullAccess	NAMPR04A001\Deleg50549-408661602	Delegate2
dan	FullAccess	NAMPR04A001\dante50549-335097617	dantest3

** So you will notice there are some unresolved accounts. These are the system managed accounts. However the accounts added by the tenant administrators will be resolved.

Hope this helps someone out there.

Exchange 2010 Set-Databaseavailabilitygroup -Alternatewitnessserver Settings Cannot Be Removed Through Powershell

Dan-O365 — Thu, 10 Jun 2010 11:26:00 GMT

I ran into this scenario a few weeks ago...

Customer installs Exchange 2010 and creates a Database Availability Group

Customer sets the AlternateWitnessServer and the AlternateWitnessDirectory parameters by using the set-databaseavailabilitygroup command.

Once a customer uses the -alternatewitnessserver and -alternatewitnessdirectory parameters to set values and decides to remove them there is no way in powershell to remove if they want to change their configuration.

If the customer tries to enter $Null for these parameters you may get "The command completed successfully but no settings of "DAGNAME" have been modified."

***If you use the same commands above with $NULL and there is not a server set already the process will find a witness server (hub server) for you the same as when you build a dag and do not specify a witness server.

The logic for the command to set these two parameters does not have the ability to remove entries. If you set $Null it will actually find a Hub server and load it for you as the witness server.

Currently you can only remove the alternatewitnessserver and alternatewitnessdirectory by using ADSIEDIT.

Open adsiedit.msc

Browse through the configuration context to Configuration>Services>Microsoft Exchange>ORGname>Administrative Group>AGname>Database Availability Groups>Dagname

If you check the properties of the DAG you can change the following values:

msExchAlternateFileShareWitness - change to by clearing the values

msExchAlternateFileShareWitnessDirectory - change to by clearing the values

Exchange 2010 get-mailpublicfolder name returns No existing 'PublicFolderProxyInformation'

Dan-O365 — Thu, 10 Jun 2010 11:21:00 GMT

Here is a recent issue I saw....

A customer migrates to Exchange 2010 environment. He replicates his public folders to other 2010 servers. On one or more of the servers he tries to get his mail enabled public folder information by using the get-mailpublicfolder command and specifying the "\publicfolder" parameter.

This will Generate an error code 4 in the application log and generate these details:

(PID 7428, Thread 125)
Task Get-MailPublicFolder writing error when processing record of index 0.
Error: Microsoft.Exchange.Data.Mapi.Common.MapiLogonFailedException: Can't logon to the the Exchange mailbox server 'contoso.com'. No existing 'PublicFolderProxyInformation' matches the following Identity: '\contoso\Test 2'. Make sure that you specified the correct 'PublicFolderProxyInformation' Identity and that you have the necessary permissions to view 'PublicFolderProxyInformation'.. ---> Microsoft.Mapi.MapiExceptionLogonFailed: MapiExceptionLogonFailed: Unable to make connection to the server. (hr=0x80040111, ec=-2147221231)
Diagnostic context:
Lid: 37053 Win32Error: 0x6A6

There is not a mailbox database mounted on the server that has the System Attendant mailbox associated with it. When the \publicfolder parameter is passed we need to access the system attendant to perform a lookup for the folder path. This seems to be visible mainly on stand alone servers as opposed to a DAG node.

Alternatively you can run the get-mailpublicfolder command with the "alias" specified and get results as expected. This is because we can look up the AD object in the MESO folder.

This is currently under investigation, but a work around is to mount a mailbox store on the server that is generating the error, or if there is a database already mounted - verify the system attendant is properly configured to point to a valid homemdb.

Welcome to my Blog

Dan-O365 — Thu, 10 Jun 2010 10:56:00 GMT

As a Microsoft Employee I have a great advantage in seeing issues as they come in and help customers. As I have data that is able to be passed on and be done by Exchange engineers I wish to pass this on to provide more support to those using Exchange Server. I hope I can provide some data that is not available anywhere else to help you out on the web. Thanks for visiting my blog!!