Full Access Permissions and AutoMapping in Exchange 2007?

Hi,
Using Exchange 2007 and Outlook 2010. I have assigned Full Access Permissions to a mailbox but I don't know how to access that mailbox in Outlook. Can anyone point me in the right direction?
I see Exchange 2010 has a feature called automapping, which will load all mailboxes I have rights to in Outlook. Is there a similar feature in Exchange 2007? If not, what do I need to do in Outlook to access the other mailbox?
Thanks in advance,
Linn

Not in Exchange 2007.
You will have to add the mailbox manually:
http://support.sherweb.com/Faqs/Show/how-to-add-another-persons-mailbox-to-your-outlook-2010-profile-exchange-2007
Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

Similar Messages

Which AD Attributes are use to store Send-As, Full-Access permissions and Calendar permissions?

Hello All,
Please, could someone tell me Which AD Attributes are use to store Send-As, Full-Access permissions and Calendar permissions?
Regards
José Osorio

Hi Jose,
Based on my test, the value of attribute msExchDelegateListLink points to Full Access permission while the
publicDelegates indicates Send on behalf permission.
As for Send as permission, it is the permission in the Access Control List which is a list of permissions attached to an object. Just like:
Thanks,
Winnie Liang
TechNet Community Support

Full access permissions and calendars

Quick question...in Exchange 2007 if you grant full access permissions on a mailbox, does it also give full owner rights to the calendar as well?
So if User A has full access permissions to User B's mailbox, do they also get Owner permissions on the calendar of User B?

Hi,
When you grant the Full Access permission to another user for a mailbox, that user becomes able to log on to the mailbox and access its entire contents. This includes calendar as well.
Grant Full Access permission is different from applying the Owner role to a folder. For more details, you can refer to the following articles.
Add-MailboxPermission:http://technet.microsoft.com/en-us/library/bb124097(v=exchg.150).aspx
Add-MailboxFolderPermission:http://technet.microsoft.com/en-us/library/dd298062(EXCHG.140).aspx
Best regards,
Belinda
Belinda Ma
TechNet Community Support

Exchange 2010 Unable to Assign Full Access Permissions using a Security Group

I've been running into this issue lately. I cannot seem to use groups to allow full access to mailboxes. When I add them from the EMC, it will show up when you go to "Manage Full Access Permission...". After waiting a day and even restarting
the Information Store service, the permissions do not take effect. When I view the msExchDelegateListLink attribute of the mailbox account, the group is not listed.
When I grant a user full permission, it works and updates the attribute. However, on occasion when I revoke the full access permission for a user is doesn't always remove that user from the msExchDelegateListLink attribute. So the mailbox
will still appear in Outlook, but the user isn't able to see new emails.
Any ideas on what may be going wrong?
Environment:
Exchange Server 2010 SP1 Standard
Windows Server 2008 R2 Standard
Outlook 2010 SP1 (tried without SP1 as well)
I was looking over Add-MailboxPermission on Technet (http://technet.microsoft.com/en-us/library/bb124097.aspx) and I noticed that it doesn't mention adding groups. Is this not possible?

I never got a proper fix.
I worked around it by creating a script which gets the members of an AD Mail Enabled security group, and updates the full access based on the groups members.
Here's a script I'm running every hour which updates permissions. It's probably not the most efficient script ever, but it works. It has several benefits
1. Managers of the distribution group can add/remove mailbox members using OWA or through the address list
2. New members of groups are added to FULL Access Permissions
3. Members removed from the groups are removed from FULL access permissions
4. Automapping works :)
5. Maintains a log of access added / removed / time taken etc.
Obviously I have had to remove domain related information, replace with whatever your domain requirements are, and PLEASE debug it properly in your environent first, don't complain to me if it wipes out a load of access for you or something like that!
It takes about 5 minutes to run in my environement. Some formatting seems to have got messed up on here, sorry. I hope it is of use!
# Mailbox Permissions Setter for Exchange #
# v1.1 #
# This script will loop through all mailboxes in Exchange and find any where #
# the type is 'SHARED'. These should be determined to be a GROUP/SHARED mailbox #
# and access to these mailboxes are controlled by a single ACL, e.g. 'ACL_Shared_Mailbox'. #
# This script will add any members of these ACLs directly to the Full Access Permissions #
# of the mailbox and also remove them if they no longer need the access. #
# Script created by Jon Read, Technical Administration
# Recent Changes
# 15/11/2012
# 1.1 Added exclusions for ACLs that we don't want automapping to happen for
# 12/11/2012
# 1.0 Initial script
#Do not change these values
Add-PSSnapin *Ex*
$starttime = Get-Date
$logfile = "C:\accesslog.txt"
$logfile2 = "C:\accesslog2.txt"
$totaladditionstomailboxes = 0
$totalremovalsfrommailboxes = 0
$totalmailboxesprocessed = 0
$totalmailboxesskipped = 0
# Exclude any ACLs that shouldn't be processed here if they are used for a non-standard purpose and
# we don't want FULL access mapping to happen. Seperate array values with commas
$ExcludedACLArray = "DOMAIN\ACL_ExcludedExample"
Write-Output " " >> $logfile
Write-Output " " >> $logfile
Write-Output "#----------------------------------------------------------------#" >> $logfile
Write-Output "# Mailbox Permissions Setter for Exchange #" >> $logfile
Write-Output "# v1.1 #" >> $logfile
Write-Output "#----------------------------------------------------------------#" >> $logfile
Write-Output " " >> $logfile
Write-Output " " >> $logfile
Write-output "Start time $starttime ">> $logfile
Write-Output " " >> $logfile
Write-Output " " >> $logfile
# Set preferred DCs and GCs
$preferredDC = "preferredDC.domain"
$preferredGC = "preferredGC.domain"
Write-Output " PreferredDC = $preferredDC ">> $logfile
Write-Output " PreferredGC = $preferredGC " >> $logfile
Set-ADServerSettings -PreferredGlobalCatalog $preferredGC -SetPreferredDomainControllers $preferredDC
# The first part of this will ADD permissions to the mailbox, reading from an associated ACL.
# Check for all mailboxes where the type is SHARED. These are the only ones we would
# want to apply group mailbox permissions to.
foreach ($mailbox in get-mailbox -resultsize "unlimited" | where-object {$_.RecipientTypeDetails -eq "SharedMailbox"})
$totalmailboxesprocessed = $totalmailboxesprocessed + 1
Write-Output " " >> $logfile
Write-Output " " >> $logfile
Write-Output "|-------------------------------------------------------" >> $logfile
Write-Output "| MAILBOX ADDITIONS: $mailbox " >> $logfile
Write-Output "|-------------------------------------------------------" >> $logfile
$mailbox=$mailbox.ExchangeGuid.ToString()
# For each of them, get the distribution list applied to the mailbox (Starting DOMAIN\ACL_)
# We then need it to be turned into a string to use later.
#Declared $changes as 0. if this is set to 0 at the end of the mailbox job, we know no changes were made.
$changes = 0
foreach ($distributiongroup in get-mailbox $mailbox | Get-MailboxPermission | Where-Object {$_.User -like "DOMAIN\ACL_*" })
$skipACL = 0
#Get the distribution group and put the name in a useable format
$distributiongroup=$distributiongroup.user.tostring()
Write-Output "Found ACL $distributiongroup" >> $logfile
# Check if this distribution group needs to be excluded and if it shouldn't be processed
# then move onto the next ACL. This will stop FULL access being granted if the mailbox is
# used for a non-standard purpose. See the start of this script
# for where these are excluded (ExcludedACLArray)
foreach ($ACL in $ExcludedACLArray )
if ($distributiongroup -eq $ACL)
$skipACL = 1
Write-Output "ACL $distributiongroup is excluded so skipping mailbox " >> $logfile
$totalmailboxesskipped = $totalmailboxesskipped + 1
if ($skipACL -eq 0)
# Get each user in this group and for each of them, add try to add them to full access permissions.
foreach ($user in Get-DistributionGroupMember -identity $distributiongroup)
# Get the user to try, convert to DOMAIN\USER to use shortly
$user="DOMAIN\" + $user.alias.ToString()
# Check to see if the user we have chosen from the ACL group already exists in the full access
# permissions. If they do, set $userexists to 1, if they do not, leave $userexists set to 0.
# Set $userexists to 0 as the default
$userexists = 0
foreach ($fullaccessuser in get-mailbox $mailbox | Get-MailboxPermission)
# See if the user exists in the mailbox access list.
# Change $fullaccessuser to a useable string (matching $user)
$fullaccessuser=$fullaccessuser.user.tostring()
if ($fullaccessuser -eq $user)
$userexists=1
# Break out of foreach if the user exists so we don't unnecessarily loop
break
# Now we know if the user needs to be added or not, so run code (if needed) to add
# the user to full access permissions
if ($userexists -eq 0)
Add-MailboxPermission $mailbox –user $user –accessrights "FullAccess"
Write-Output "Added $user " >> $logfile
$changes = 1
$totaladditionstomailboxes = $totaladditionstomailboxes + 1
#Now repeat for other users in the ACL
#if changes were 0, then log that no changes were made
if ($changes -eq 0)
Write-Output "No changes were made." >> $logfile
Write-Output " " >> $logfile
Write-Output " " >> $logfile
Write-Output "---------------------------------------------------------------------------------" >> $logfile
Write-Output " FINISHED ADDING PERMISSIONS" >> $logfile
Write-Output "---------------------------------------------------------------------------------" >> $logfile
Write-Output " " >> $logfile
# The second part of this will REMOVE permissions from the mailbox, reading from an associated ACL.
## Check for all mailboxes where the type is SHARED. These are the only ones we would
## want to apply group mailbox permissions to.
foreach ($mailbox in get-mailbox -resultsize "unlimited" | where-object {$_.RecipientTypeDetails -eq "SharedMailbox"})
Write-Output " " >> $logfile
Write-Output " " >> $logfile
Write-Output "|-------------------------------------------------------" >> $logfile
Write-Output "| MAILBOX REMOVALS : $mailbox " >> $logfile
Write-Output "|-------------------------------------------------------" >> $logfile
$mailbox=$mailbox.ExchangeGuid.ToString()
#Declared $changes as 0. if this is set to 0 at the end of the mailbox job, we know no changes were made.
$changes = 0
# For the current mailbox, get a list of all users with FULLACCESS, and then for each of them
# check if they exist in the ACL
foreach ($fullaccessuser in get-mailbox $mailbox | Get-MailboxPermission | Where-Object {$_.Accessrights -like "FullAccess" })
# Get the security identifier (SSID) of the FULLACCESS user to store for later.
$fullaccessuserSSID=$fullaccessuser.user.SecurityIdentifier.ToString()
$fullaccessuser=$fullaccessuser.User.ToString()
#If user needs to be excluded then skip this bit
#Users added or removed will only start with 07 (07$, 07T, so only run if the user starts with this.
#This stops it trying to remove NT AUTHORITY\SELF and other System entries
if ($fullaccessuser -like "DOMAIN\07*")
# Set $userexists to be 0. if we find the use user needs to remain, then change it to 1.
$userexists=0
# Check if this user exists in the ACL, if not, remove.
foreach ($distributiongroup in get-mailbox $mailbox | Get-MailboxPermission | Where-Object {$_.User -like "DOMAIN\ACL_*" })
$distributiongroup=$distributiongroup.user.tostring()
#Write-Output "Found associated distribution group $distributiongroup" >> $logfile
# Get each user in this group and for each of them, See if it matches the user in the mailbox.
foreach ($user in Get-DistributionGroupMember -identity $distributiongroup)
# Get the user to try, convert to DOMAIN\USER to use shortly
$userguid = $user.Guid.ToString()
$user="DOMAIN\" + $user.alias.ToString()
if ($fullaccessuser -eq $user)
$userexists=1
#we have found the user exists so no need to continue
break
# If userexists = 0, then they are NOT in the ACL, and should be removed from
# the full access permissions. Run the code to remove them from full access.
#CONVERT FULLACCESSUSER TO GUID AND REMOVE $FULLACCESSUSERGUID NOT $USERGUID
if ($userexists -eq 0)
Remove-MailboxPermission -Identity $mailbox –user $fullaccessuserSSID –accessrights "FullAccess" -Confirm:$false
Write-Output "Removed $fullaccessuser " >> $logfile
$changes = 1
$totalremovalsfrommailboxes = $totalremovalsfrommailboxes + 1
# if changes = 0, no changes were made to this mailbox, so log this fact.
if ($changes -eq 0)
Write-Output "No changes were made." >> $logfile
#Put the time in a displayable format
$endtime = Get-Date
$runtime = $endtime - $starttime
$runtime = $runtime.ToString()
$runtime1 = $runtime.split(".")
$totaltime = $runtime1[0]
Write-Output " " >> $logfile
Write-Output " " >> $logfile
Write-Output "|-------------------------------------------------------------------------------------- " >> $logfile
Write-Output "| SCRIPT COMPLETE : STATS " >> $logfile
Write-Output "|-------------------------------------------------------------------------------------- " >> $logfile
Write-Output "| Total Mailboxes Processed : $totalmailboxesprocessed " >> $logfile
Write-Output "| Total Additions : $totaladditionstomailboxes " >> $logfile
Write-Output "| Total Removals : $totalremovalsfrommailboxes " >> $logfile
Write-Output "| Total Mailboxes Skipped due to ACL : $totalmailboxesskipped " >> $logfile
Write-output "| Start time : $starttime ">> $logfile
Write-output "| End time : $endtime ">> $logfile
Write-Output "| **END OF RUN** - Elapsed time : $totaltime " >> $logfile
Write-Output "|---------------------------------------------------------------------------------------" >> $logfile
Write-Output " " >> $logfile

Full Access Permissions in Exchange

I need to be able to restrict my IT employees from having the ability to make changes to "Manage Full Access Permissions..." in MS Exchange. I will only have one or two employees who can edit this feature. Please let me know if you have any ideas.
Thank you!
Drew Kotil

Hi Drew,
From your description, I recommend you run the following cmdlet to check who is the member of Organization Management role group at first.
Get-RoleGroupMember "organization management"
Secondly, you can use the Remove-RoleGroupMember "organization management" -member xxx cmdlet to remove other IT employees from Organization Management role group.
(Note: After running the Remove-RoleGroupMember "organization management" -member xxx cmdlet, other IT employees won't have permission to perform organizational-level administrative tasks.)
Here are some articles for your reference.
Organization Management
http://technet.microsoft.com/en-us/library/dd335087(v=exchg.141).aspx
Remove-RoleGroupMember
http://technet.microsoft.com/en-us/library/dd638208(v=exchg.141).aspx
Hope it helps.
If you need further assistance, please feel free to let me know.
Best regards,
Amy
Amy Wang
TechNet Community Support

Who has full access on all mailboxes in Exchange 2010 using Powershell ?

Greetings,
Could you please tell me how can i know Who has full access on all mailboxes in Exchange 2010 using Powershell ?
Thanks.
Redouane SARRA

This is going to depend greatly on WHICH inherited permissions you plan to delete - there are some that you can never delete if you want the system to function properly. Now, that being said, let's look at some example permissions. First, here
are some permissions on a standard mailbox:
Identity             User                 AccessRights
IsInherited Deny
users.corp.... USERS\btwatcher    {FullAccess}
False       False
users.corp.... USERS\svcactAdmin {FullAccess}
True        False
users.corp.... CORP\Domain Ad... {FullAccess}
True        True
users.corp.... CORP\Enterpris... {FullAccess}
True        True
users.corp.... CORP\Organizat... {FullAccess}
True        True
users.corp.... CORP\adminact    {FullAccess}
True        True
users.corp.... CORP\esswin       {FullAccess}
True        True
users.corp.... USERS\svcactEncase {FullAccess}
True        False
users.corp.... CORP\Exchange ... {FullAccess}
True        False
users.corp.... NT AUTHORITY\SYSTEM {FullAccess}
True        False
As you can see, the first is not inherited. All others are, and two are from service accounts (svcact...). Also, some are Exchange system permissions, some are denies, and some are just administrative accounts. Once you determine which
you wish to remove, the SIMPLEST way to set the permissions you want is to open the account properties in ADSIEdit, and go to the Security tab. Here, click the Advanced button and find the inherited permission you wish to remove. ADSIEdit will
show where the permission is inherited from - you will need to go to that container to remove the inherited permission. You can also grant inherited denies at the same level(s).
Now, something you will need to understand is that if you hope to remove permissions granted to domain administrators, the system will replace them - these permissions are required by the system and can't be modified permanently.

Troubleshooting and Introduction for Exchange 2007/2010 AutoDiscover - Details about "Test E-mail AutoConfiguration"

AutoDiscover is a new feature in Exchange 2007, to provide access to Microsoft Exchange features (OAB, Availability service, UM) for Outlook 2007
clients or later.
We can determine whether problems related to AutoDiscover via OWA.
For example:
OOF is not working in Outlook Client but it is working in OWA.
When we realized this issue is not related to Outlook Client side and network side after performing some troubleshooting steps, it should be something
abnormal on AutoDiscover.
There is a common tool to check AutoDiscover in Outlook, Test E-mail AutoConfiguration.
Today, we will introduce AutoDisocver and “Test E-mail AutoConfiguration” in details. Hope it is helpful for AutoDiscover troubleshooting and self-learning.
1. Differences between “Test E-mail AutoConfiguration” and other tools
The “Test-OutlookWebServices” cmdlet allows us to test the functionality of the following services:
Autodisocver
Exchange Web Services
Availability Service
Offline Address Book
When we run “Test-OutlookWebServices”, it returns all the web services’ states.
However, some information are useless for some scenarios.
For example:
We just want our Exchange 2010 Server working internally. So it is unnecessary to enable Outlook Anywhere.
However, when we run “Test-OutlookWebServices”, it returns Outlook Anywhere errors because the Outlook Anywhere does not need to been enabled.
In contrast, using “Test E-mail Autodiscover” is more intuitive.
If there is any problems, it will return error code from the test result, like 0x8004010F etc. We can do some research from TechNet articles or MS
KBs.
Although it is difficult to say where the specific problem is just via the error codes, we can combine with IIS logs to perform troubleshooting and
find the root of problem.
2. How to use “Test E-mail AutoConfiguration” Tool
a. Open Outlook, we can find there is an Outlook Icon at the right bottom of System tray. Holding down “Ctrl” button and right click the Outlook Icon, we will see “Test E-mail
AutoConfiguration” option. Please see Figure 01.
Figure 01
b. Click “Test E-mail AutoCofiguration” and input user name, uncheck the “Use Guessmart” and “Secure Guessmart Authentication” checkboxes, then click “Test”. Please see
Figure 02.
Figure 02
c. “Test E-mail AutoConfiguration” result panel and log panel. Please see Figure 03 and Figure 04.
Figure 03
Figure 04
3. How to understand “Test E-mail AutoConfiguration” result
According to the Figure 03, we found there are many URLs in the “Test E-mail AutoConfiguration” result panel. Let us understand the details of these
URLs.
If we these URLs are not the correct ones, we can re-setting or re-creating them via commands.
- Internal OWA URL:
https://vamwan310.vamwan.com/owa/
OWA internal access.
- External OWA URL:
https://mail.vamwan.com/owa/
OWA external access.
- Availability service URL:
https://vamwan310.vamwan.com/EWS/Exchange.asmx
Free/Busy, OOF and meeting suggestions.
- OOF URL:
https://vamwan310.vamwan.com/EWS/Exchange.asmx
Out of Office access.
- OAB URL:
https://vamwan310.vamwan.com/OAB/023ef307-b18a-4911-a52c-de26700f6173/
OAB access.
- Exchange Control Panel URL:
https://vamwan310.vamwan.com/ecp/
ECP access.
4. AutoDiscover Tips
- AutoDiscover Service itself is a web application running on the AutoDiscover virtual directory (not a server service) designed to provide connection information to various
clients.
- The AutoDiscover service is automatically installed and configured when CAS role is added to any Exchange Server.
- AutoDisocver virtual directory is created in IIS within the Default Web Site.
- A Sercive-Connection-Point (SCP) object is created in AD.
- The SCP contains a URL to the AutoDiscover service. This is for intranet clients so they do not have to use DNS to locate the AutoDiscover service.
- In AD this object is located at the following location:
DC=<domain>, CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=First Organization, CN=Administrative Groups, CN=Exchange Administrative
Group, CN=Servers, CN=<CAS Name>, CN=Protocols, CN=AutoDiscover, CN=<CAS Name>
- Setup creates the AutoDiscover URL based on the following structure:
<CASNetbiosName>.domain.com/AutoDiscover/AutoDiscover.xml
If a PKI certificate is not already present, a self-signed certificate is installed on the Default Web Site.
To help allow this certificate pass the Issues to test it is set up with a Subject Alternative Name containing urls.
If a PKI certificate is present, that certificate is utilized and configured for use in IIS.
The Outlook Provider is used to configure separate settings for the Exchange PRC protocol (internal to network), Outlook Anywhere (Exchange HTTP protocol), and WEB:
EXCH, EXPR, WEB
The
EXCH and EXPR setting are vital for the proper configuration of Outlook.
5. AutoDiscover Workflow
General Process flow:
There are various components surrounding the AutoDiscover Service and all are necessary to complete a request. Including IIS, AutoDiscover service
itself, the provider, and AD.
a.
Client constructs service URL and submits Autodiscover Request. First attempt to locate the SCP object in AD. So, DNS is not needed.
b.
IIS Authenticates User.
c.
Is the Autodiscover service in the appropriate forest?
+ If YES.
    1)
Parse/Validate Request
    2)
Is there a provider that can service the Request?
++ If YES
      a)
Config provider processes request and returns config settings.
      b)
Return config setting to client
++ If NO
Inform client we cannot process request
+ If NO.
Redirect client to Autodiscover service in the appropriate forest.
Methods to find Autodiscover services: SCP and DNS
Domain-joined
a. Find SCP first.
The SCP contains the URL to the AutoDiscover service.
URL: https://CAS01.contoso.com(CAS’ FQDN)/AutoDiscover/AutoDiscover.xml
If more than one SCP object is found in AD (it means there are multiple CAS servers in the Exchange organization), Outlook client will choose one of the SCP entries that
are in the same site to obtain the AutoDisocover URL.
b. If we cannot find SCP object, then Outlook client will use DNS to locate AutoDiscover.
Outlook parses out the domain (SMTP suffix) via your EmaiAddress, then attempts to connect to the predetermined order of URLs via the suffix.
For example: If my email address is
[email protected]
Outlook tries POST commands to the following order of URLs:
https://contoso.com/autodiscover/autodiscover.xml
https://autodiscover.contoso.com/autodiscover/autodiscover.xml
NOTE: The URLs above is by design, hardcode
and cannot be changed.
c.
If those fail, Outlook tries a simple redirect to another URLs in IIS:
http://contoso.com/autodiscover/autodiscover.xml
http://autodiscover.contoso.com/autodiscover/autodiscover.xml
If none of these URLs work then DNS is most likely not set up correctly.
We can test that by pinging one of the above URLs.
If that is successful, we must ensure the URLs contoso.com or autodiscover.contoso.com are actually pointing to the CAS server.
If the ping fails then there is a chance that DNS is not set up correctly so be sure to check that the URLs are even registered.
NOTE: If contoso.com is a non-CAS server,
we should add a Host record with just AutoDiscover. And point that entry to your CAS server that is running AutoDiscover.
d.
If still failed, we can use DNS SRV lookup for _autodiscover._tcp.contoso.com, then “CAS01.contoso.com” returned. Outlook will ask permission from the user to continue
with AutoDiscover to post to https://CAS01.contoso.com/autodiscover/autodiscover.xml
Non-Domain-joined
It first tries to locate the Autodiscover service by looking up the SCP object in AD. However the client is unable to contact AD, it tries to locate
the Autodiscover service by using DNS.
Then, same as step b, c, d in
Domain-joined scenario.
6. How to change the AutoDiscover
service location order forcibly?
By default, Outlook client locates AutoDiscover service in that order above.
We can also change the order forcibly.
a.
If we want to locate AutoDiscover service via one of the autodiscover URLs, please running following command in EMS:
Set-ClientAccessServer -identity <servername> -AutodiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml(URL
that you want)
b. If we want to locate AutoDiscover service via
SRV record, please follows this KB to set up SRV:
http://support.microsoft.com/kb/940881
7. How to check AutoDiscover Healthy
a. We should make sure the AutoDiscover
is healthy before using AutoDiscover to perform troubleshooting.
b.
We can browse following URL in IE explorer:
https://autodiscover.vamwan.com/autodiscover/autodiscover.xml
If it returns “code 600”, that means AutoDiscover is healthy.
Screenshot as below:
c. AutoDiscover itself returns errors to the requesting client if the incoming request does not contain the appropriate information to complete a
request.
The following table explains the possible errors that could be returned.
Error Value
Description
600
Mailbox not found and a referral could not be generated.
601
Address supplied is not a mailbox. The provided email address is not something a client can connect to. It could
be a group or public folder.
602
Active Directory error.
603
Others.
The 600 “Invalid Request” error is returned because a user name was not passed to the service. That is OK for this test because this does confirm
the service is running and accepting requests.
d.
If AutoDiscover service is not working well, I suggest re-building the AutoDiscover Virtual Directory for testing.
Steps as below:
1) Running following command in EMS to remove the AutoDiscover VD (we cannot delete it via EMC):
Remove-AutodiscoverVirtualDirectory -Identity "CAS01\autodiscover(autodiscover.contoso.com)"
Please refer:
http://technet.microsoft.com/en-us/library/bb124113(v=exchg.141).aspx
2)
Running following command in EMS to verify whether we have removed the AutoDisocver VD successfully:
Get-AutodiscoverVirtualDirectory | FL
Please refer:
http://technet.microsoft.com/en-us/library/aa996819(v=exchg.141).aspx
3)
Running following command in EMS to re-creating a new AutoDiscover VD:
New-AutodiscoverVirtualDirectory -Websitename <websitename> -BasicAuthentication:$true -WindowsAuthentication:$true
Please refer:
http://technet.microsoft.com/en-us/library/aa996418(v=exchg.141).aspx
8. Common issues
a. Outlook Disconnection
Issue and Troubleshooting
Issue:
Sometimes the Outlook clients cannot connect to the Exchange server after migrating to a new Exchange server or changing to new CAS. The Outlook clients
always connect to the old CAS server.
Troubleshooting:
To solve this issue, we should change the SCP via following command:
Set-ClientAccessServer -Identity
<var>CAS_Server_Name</var> -AutodiscoverServiceInternalUri
https://mail.contoso.com(newCAS’FQDN)/autodiscover/autodiscover.xml
b. Autodiscover
Certificate issue
Tips on Certificate:
Exchange requires a certificate to run an SSL protocol such as HTTPS. We can use the certificate that supports subject alternate names (SAN) in Exchange.
This is to allow the certificate to support resources that have different names, such as Outlook Anywhere and the Autodisocver Web application.
Issue and Troubleshooting
Issue:
We receiver the Certificate Principal Mismatch error when we use a SAN certificate.
Troubleshooting:
1) Please determine the FQDN that the client
uses to access the resource. Steps as below:
OutlookàToolsàAccount
SettingsàE-mailàclick
the Exchange accountàChangeàMore
SettingsàConnectionàExchange
Proxy Settingsànote the FQND that list in the
Only connect to proxy servers that have this principal name in their certificate box.
2)
Please using EMS to determine the value for the CerPrincipalName attribute: Get-OutlookProvider
This command returns the result for the EXPR name.
3)
Please re-setting the CertPrincipalName attribute to match the FQDN via following command:
Set-OutlookProvider EXPR –CertPrincipalName: “msstd:<FQDN the certificate is issued to>”
9. Resource for reference:
Autodiscover and Exchange 2007
http://technet.microsoft.com/en-us/library/bb232838(v=exchg.80).aspx
White Paper: Understanding the Exchange 2010 Autodiscover Service
http://technet.microsoft.com/en-us/library/jj591328(v=exchg.141).aspx
Certificate Principal Mismatch
http://technet.microsoft.com/en-us/library/aa998424(v=exchg.80).aspx
Please click to vote if the post helps you. This can be beneficial to other community members reading the thread.

HI,
I get following? when run the test? user is login to Domain A but accessing exchange in Domain B?

Auto-Mapping with Full Access Mailboxes-not working in exchange 2010 clients outlook 2013

hello, I have exchange server 2010, the clients are running outlook 2013, I set an mailbox for automapping (full access) but when i restart client it does not appear in the client. i also did the command in the exchange shell, no errors. how can i fix this.

no sp info shows with the
Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersionName
Edition : Enterprise
AdminDisplayVersion : Version 14.0 (Build 639.21)
chart says
Exchange Server 2010 November 9, 200914.00.0639.021
is that the issue need sp 1?

Exchange 2013 owa integration with ADFS and cooexistance with exchange 2007

Team,
I have successfully integrated adfs 3.0 and Exchange 2013 owa and ecp. However, we have a coexistence environment with exchange 2007. When you access owa, which then redirects you to adfs, sign-in, and then get redirected back to owa. If your
mailbox is still within exchange 2007, you get a blank login page. If you mailbox is in exchange 2013 then you successfully get the owa page for 2013. The problem is that all exchange 2007 mailbox users get blank pages at login. So I have determined
that exchange 2013 cas is not doing the service location lookup on the mailbox to determine if a redirect to the legacy owa address is needed. Is there a configuration setting that I might be missing? Or does the integration with adfs and owa not support
the much needed mailbox lookup for a coexistance environment? A side note: if we enable FBA with owa, both login scenarios work just fine (legacy and new 2013). The legacy namespace has been created, and applied to the exchange 2007 urls.

Hi,
Try using AD FS claims-based authentication with Outlook Web App and EAC
http://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx
Thanks,
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
[email protected]
Simon Wu
TechNet Community Support

New User cannot access OWA after migrate from Exchange 2007 to Exchange 2013

Dear all,
I recently migrate the Exchange server from Exchange 2007 on Windows Server 2003 to Exchange 2013 on Windows 2012 R2. I can open the mailbox moved from Exchange 2007 without any problem. However when I created a new user in Exchange 2013, the user cannot
login the OWA, the browser will throw out following screen. Can anyone help me in this case. Thanks a lot!

Hi Winnie,
Thank for your reply. Below is the result, please note there has four exchange servers, HKAD and HKEX are the existing Exchange 2007 server. HKCAS1 and HKCAS2 are the new Exchange Server 2013 - both of xchange server 2013 are using owa.ksi.com.hk
as the external URL.
Identity                      : HKAD\owa (Default Web Site)
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           : {}
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
https://hkad.ksi.com.hk/owa
ExternalUrl                   :
Identity                      : HKAD\Exchange (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : False
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           :
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
ExternalUrl                   :
Identity                      : HKAD\Public (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : False
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           :
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
ExternalUrl                   :
Identity                      : HKAD\Exchweb (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : False
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           :
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
ExternalUrl                   :
Identity                      : HKAD\Exadmin (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : False
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           :
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
ExternalUrl                   :
Identity                      : HKEX\owa (Default Web Site)
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           : {}
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
https://hkex.ksi.com.hk/owa
ExternalUrl                   :
Identity                      : HKEX\Exchange (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : False
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           :
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
ExternalUrl                   :
Identity                      : HKEX\Exadmin (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : False
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           :
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
ExternalUrl                   :
Identity                      : HKEX\Public (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : False
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           :
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
ExternalUrl                   :
Identity                      : HKEX\Exchweb (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : False
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           :
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
ExternalUrl                   :
Identity                      : HKCAS2\owa (Default Web Site)
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           : {}
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
https://hkcas2.ksi.com.hk/owa
ExternalUrl                   :
https://owa.ksi.com.hk/owa
Identity                      : HKCAS1\owa (Default Web Site)
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
Url                           : {}
SetPhotoURL                   :
Exchange2003Url               :
FailbackUrl                   :
InternalUrl                   :
https://hkcas1.ksi.com.hk/owa
ExternalUrl                   :
https://owa.ksi.com.hk/owa

Export Mailbox from Exchange 2010 and Import to Exchange 2007

Hello,
I exported mailbox (1GB in size) from Exchange 2010 to *.pst file; I need to import it into
Exchange 2007 mailbox. Is it supported ?
The operation completed successfully (no errors) but no items were imported; is it due to unsupported backward compatibility or some other issue ?
Thank you,
Luca
Disclaimer: This posting is provided AS IS with no warranties or guarantees, and confers no rights. Whenever you see a helpful reply, click on [Vote As Help] and click on [Mark As Answer] if a post answers your question.

I also have the same issue. Exported mailboxes on Exchange 2010 SP3 latest updates using
New-MailboxExportRequest and then tried to import into mailbox on Exchange 2007 SP3 with latest updates. The 32-bit client machine used for the import has Outlook 2010 SP1 (SP2 and later updates causes a different error). I used Outlook 2010 because the E2K10
New-MailboxExportRequest documentation states that you have to use Outlook 2010 or later. The PST files created can be opened and imported via Outlook but not with the
Import-Mailbox cmdlet (with no error as stated in this thread). Other PSTs, not created from E2K10 export do import just fine. I also ran ScanPST.exe against the exported PST and then ran the import again and it worked, everything got imported. Interestingly
the test mailbox PST file I was using was 761 KB but after the ScanPST it was 1,257 KB - must be some difference in the PST format that the Import-Mailbox cmdlet can't deal with.
Does anyone have any other solutions or
workarounds to this. I've got over 900 mailboxes I need this for due to an
acquisition? Has anyone tried using Outlook 2013 on the machine used for doing
the Exchange 2007 imports or does Outlook 2013 also have the same issue as later versions of Outlook 2010 (Exchange Mailbox import failed with error code 2147221233)?

HTTP 500 error when opening a legacy shared mailbox in OWA 2013 (Exchange 2007/2013 coexistence environment)

Hi,
Our Exchange 2013/2007 coexistence environment is set up and all is working apart from this:
Mailbox A has full permissions to Mailbox B. Mailbox A is migrated to Exchange 2013, but Mailbox B remains on Exchange 2007. If I login to Outlook Web App 2013 as Mailbox A and then "Open another mailbox..." and select Mailbox B, a new window opens
up saying "HTTP 500 Internal Server Error". The URL it is trying is :
https://webmail.ourdomain.com/owa/[email protected]/?offline=disabled
( I can open Mailbox A in Outlook 2010 and do "Open Other users's folder.." and Mailbox B opens up just fine. )
Our legacy CAS server's External and Internal URLs are set to :
https://legacy.ourdomain.com/owa
and the Exchange 2013 CAS server's External and Internal URLs are set to :
https://webmail.ourdomain.com/owa
We have FBA enabled on both the E2K7 and E2K13 OWA
In the IIS logs:
2015-03-02 16:36:50 <E2K13_IP> POST /owa/service.svc action=SubscribeToNotification&UA=0&ID=-25&AC=1&CorrelationID=c2899211-568d-4da4-a163-351a8621c9fd_142531419466924;&cafeReqId=7ffae082-a96f-42fd-85f8-bf23775ed5de; 443 ourdomain.com\MailboxA
<LoadBalancer_IP> Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0)
https://webmail.ourdomain.com/owa/#path=/mail 200 0 0 109
2015-03-02 16:36:50 <E2K13_IP> GET /owa/ offline=disabled&CorrelationID=<empty>;&cafeReqId=7c8e137f-cdb7-4449-9cb8-f36f94539244; 443 ourdomain.com\MailboxA <LoadBalancer_IP> Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0)
- 500 0 0 265
In the OWA HTTP Proxy logs:
2015-03-02T16:36:50.096Z,7c8e137f-cdb7-4449-9cb8-f36f94539244,15,0,913,7,,Owa,webmail.ourdomain.com,/owa/,,FBA,True,ourdomain.com\MailboxA,ourdomain.com,[email protected],Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2;
.NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0),<LoadBalancer_IP>,<Exchange2013ServerName>,500,,ServerNotFound,GET,,,,,ExplicitLogon-SMTP-Header,,,,0,,,,40,9,,0,7;,7,,0,7,,0,46.8643,0,,,,,,,,,1,10,0,,10,,50,50,?offline=disabled,,BeginRequest=2015-03-02T16:36:50.049Z;CorrelationID=<empty>;ProxyState-Run=None;ServerLocatorRefresh=beebf732-0f99-47a0-9f36-d266573f1510;RefreshingCacheEntry=CacheEntry(BackEndServer
<Exchange2007ServerName>.ourdomain.com~1912832083|ResourceForest |LastRefreshTime 2015-03-02T16:01:29.3265514Z|IsSourceCachedData False);ProxyState-Complete=CalculateBackEnd;EndRequest=2015-03-02T16:36:50.096Z;I32:ADS.C[<DC_Name>]=1;F:ADS.AL[<DC_Name>]=6.6401;I32:ATE.C[<DC_Name>.ourdomain.com]=1;F:ATE.AL[<DC_Name>.ourdomain.com]=0,HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException:
The server <Exchange2013ServerName>.ourdomain.com was not found in the topology. ---> Microsoft.Exchange.Data.Storage.ServerNotFoundException: The server <Exchange2013ServerName>.ourdomain.com was not found in the topology.
at Microsoft.Exchange.Data.Storage.ServiceTopology.GetSite(String serverFullyQualifiedDomainName)    at Microsoft.Exchange.Data.ApplicationLogic.Cafe.HttpProxyBackEndHelper.GetServiceTopologyWithSites(String serverFqdn ServiceTopology
topology)    at Microsoft.Exchange.Data.ApplicationLogic.Cafe.HttpProxyBackEndHelper.GetE12ExternalUrl[ServiceType](BackEndServer mailboxServer)    at Microsoft.Exchange.HttpProxy.OwaProxyRequestHandler.GetE12TargetServer(BackEndServer
mailboxServer)    at Microsoft.Exchange.HttpProxy.BEServerCookieProxyRequestHandler`1.GetDownLevelClientAccessServer(AnchorMailbox anchorMailbox BackEndServer mailboxServer)    at Microsoft.Exchange.HttpProxy.LatencyTracker.GetLatency[T](Func`1
operationToTrack Int64& latency)    at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalOnCalculateTargetBackEndCompleted(TargetCalculationCallbackBeacon beacon)    at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass3b.<OnCalculateTargetBackEndCompleted>b__3a()
--- End of inner exception stack trace ---;
Hoping that somebody can help ?
Thanks

Hi Ansev,
Thank you for your question.
By my testing, user who was migrated to Exchange 2013 cannot access mailbox on Exchange 2007 with 500 error, although user account have “Full Access Permission” to mailbox on Exchange 2007.
I suggest we migrate account which has “Full Access Permission” for other user to Exchange 2013.
If there are any questions regarding this issue, please be free to let me know.
Best Regard,
Jim
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
Jim Xu
TechNet Community Support

Single mailbox manage permissions issues full access/send as

Exchange 2010 SP3 RU7
I have a weird issue with one mailbox. This user has 2 AD accounts. Say "userprimary" and "usersecondary". This user was set up by another admin that is no longer here. "userprimary" is the actual mailbox
account.
User logs on to workstation using "usersecondary" AD credentials and manually sets up outlook 2010 to connect to "userprimary" mailbox. The userprimary mailbox has manage full access permissions assigned to it for the usersecondary
account. The userprimary mailbox does NOT have "send as permissions" set up. When the user logs in with "usersecondary" he can access the mailbox fine but can also send email. In theory he shouldn't be able to send as
there are no send as permissions set up on the "userprimary" mailbox.
How is this happening and what can I check to resolve this.

Userprimary account > manage full access > add usersecondary account.
Userprimary account > manage send as > nothing exists here.
Person logs onto workstation as usersecondary ad account
Person configures outlook to use userprimary account. (supplies no additional credentials)
Person launches outlook and is able to open userprimary account and send and receive emails.
Both AD accounts are Domain Admins.
Person doesn't need to have under the userprimary account, send as permissions with the usersecondary account specified. Reason seems that in AD, domain admins have 'send as' and 'receive as' set for all accounts.

Previous Exchange Admin has somehow granted himself inherited Full access rights to All Exchange Mailboxes -AccessRights -InheritanceType

Good Day,
There is a previous employee that was a Systems Admin and somehow he granted himself access to Every Mailbox item at one point in time and the cleanup has been a bit messy.
When this user is listed as "Full Access Granted" in the Manage Full Access Permissions function, and I delete him, I get a confirmation that he was removed, but then an additional item below it. (This is depicted in the attached photo)
How do I remove the hierarchical inheritance of this user?
the commands in the photo show:
Remove-Mailboxpermission -identity %OU String% -user %user% -inheritancetype 'All' -Accessrights 'FullAccess'
Add-Mailboxpermission -identity %OU String% -user %user% -Deny -Accessrights 'FullAccess'

Hello,
I have removed permission to this user in ADSI Edit Microsoft Exchange Configuration CN and ensured that his name was no where to be found in the ADSI permissions for Exchange. I was running the following command:
Get-Mailbox | Remove-MailboxPermission -User %USER% -AccessRights FullAccess,SendAs,Exter
nalAccount,DeleteItem,ReadPermission,ChangePermission,ChangeOwner -InheritanceType All
and I get a return warning:
WARNING: An inherited access control entry has been specified: [Rights: CreateChild, Delete, ReadControl, WriteDacl,
WriteOwner, ControlType: Allow]
and was ignored on object "CN=%FullAccessUser%"
How can I ensure that this user had NO permissions at all to the exchange mailboxes?

Exchange Admin without the right to assign / revoke the Full Access Permission

Hello,
I would like to create Exchange Administrator who can do all mail box related administration except assign/revoke Full Access Permission and Send As Permission to other users' mail box or hims own mail box.
Exchange: MS Exchange 2007
OS: Windows 2008

You would have to regularly update his rights on the mailboxes - you can't grant the rights to the distribution group and have them apply to the mailboxes it contains. This means that when someone moves from his department, you would need to immediately
have to remove his rights from that mailbox, since just basing his rights on mailboxes in the group would add more members, but never remove him from existing ones.
For instance, in your list above, Bill manages John, Paul, Jim, and Harry. Suppose Harry moves from Bill's department, and Dave joins it. If you just go by group membership, Dave would get added, but there's no easy way to see that Harry is no
longer in the department. You would either have to mark this in the notes of the group ("Harry left 3/16/2015'), or you would have to immediately remove Harry from the group. Consider if Harry was promoted to Bill's level - he wouldn't want
Bill to have rights on his mailbox just because he had them when he was Bill's direct report.
As for a script you can run each week to add the mailbox rights, that's pretty simple. You'd use
Get-Group <group alias> | % { $_.Members } to get the list of group members, and you'd use
Add-MailboxPermission $ChkMbx -User $_.Alias -AccessRights FullAccess
to add the full mailbox access rights. The following would be a good starting point:
Get-Group <group alias> | % { $_.Members } | % {
Add-MailboxPermission $_.DistinguishedName -User <manager alias> -AccessRights FullAccess
I'll caveat this response - I have Exchange 2010 and don't have an Exchange 2007 system to check the commands or their syntax with. Your mileage may vary.

Full Access Permissions and AutoMapping in Exchange 2007?

Similar Messages

Maybe you are looking for