Hi,

i have test of Exchange 2013 SP1 CU7. Seems, that all works good. Users can login over OWA, send emails each other.

In ECP i see all 50 mailboxes. In powershell - only one! Why? how i can fix it?

[PS] C:\>get-mailbox -Identity "*"

Name                      Alias                ServerName       ProhibitSendQuota
----                      -----                ----------       -----------------
User 1                     User 1                 ex1              Unlimited

[PS] C:\>Get-Mailboxdatabase

Name                           Server          Recovery        ReplicationType
----                           ------          --------        ---------------
Mailbox Database 1363112588    EX1             False           None
base1                          EX1             False           None
all                            EX1             False           None

User 1 belong to base1, but into this base there are more mailboxes.

Thank you!

• Edited by Anahaym Tuesday, May 12, 2015 9:50 AM

Please try after running this command

Set-AdServerSettings -ViewEntireForest $true -PreferredGlobalCatalog <gc.domain.com>

Are you getting the same result when running command get-mailbox?

nothing changed
still only one User

• Edited by Anahaym Tuesday, May 12, 2015 1:54 PM

Get-MailboxDatabase | Get-Mailbox

[PS] C:\>Get-MailboxDatabase | Get-Mailbox
Some of the parameters specified with the "Get-Mailbox" cmdlet aren't present in the role definition for the current user. Check the management
roles assigned to you, and try again.
    + CategoryInfo          : PermissionDenied: (:) [Get-Mailbox], CmdletAccessDeniedException
    + FullyQualifiedErrorId : [Server=EX1,RequestId=8f4353bc-70b8-4002-9aae-a6be740e801d,TimeStamp=12.05.2015 14:28:28] [FailureCategory=Cmdlet-Cmdl
   etAccessDeniedException] 98B25FB9,Microsoft.Exchange.Management.RecipientTasks.GetMailbox
    + PSComputerName        : ex1.domain.internal

i compared membership with domain\administrator. what is missing?

[PS] C:\>Get-ADUser -Identity aleks -Properties memberof | Select-Object MemberOf

MemberOf : {
CN=import,OU=Microsoft Exchange Security Groups,DC=domain,DC=internal,
CN=Server Management,OU=Microsoft Exchange Security Groups,DC=domain,DC=internal,
CN=Recipient Management,OU=Microsoft Exchange Security Groups,DC=domain,DC=internal,
CN=Organization Management,OU=Microsoft Exchange Security Groups,DC=domain,DC=internal,
CN=Domain Admins,CN=Users,DC=domain,DC=internal,
CN=Enterprise Admins,CN=Users,DC=domain,DC=internal,
CN=Schema Admins,CN=Users,DC=domain,DC=internal
}

[PS] C:\>Get-ADUser -Identity administrator -Properties memberof | Select-Object MemberOf

MemberOf : {
CN=import,OU=Microsoft Exchange Security Groups,DC=domain,DC=internal,
CN=Server Management,OU=Microsoft Exchange Security Groups,DC=domain,DC=internal,
CN=Recipient Management,OU=Microsoft Exchange Security Groups,DC=domain,DC=internal,
CN=Organization Management,OU=Microsoft Exchange Security Groups,DC=domain,DC=internal,
CN=Group Policy Creator Owners,CN=Users,DC=domain,DC=internal,
CN=Domain Admins,CN=Users,DC=domain,DC=internal,
CN=Enterprise Admins,CN=Users,DC=domain,DC=internal,
CN=Schema Admins,CN=Users,DC=domain,DC=internal,
CN=Administrators,CN=Builtin,DC=domain,DC=internal
}

By Administrator all works.

• Edited by Anahaym Tuesday, May 12, 2015 3:30 PM

Hi Anahaym,

As we have pointed this out as issue with you particular EMS sessions for Aleks.

Run EMS as were it doesnt work. Let me know the results for below cmdlets:

$env:username

[Environment]::UserName

[Environment]::UserDomainName

[Environment]::MachineName

Please note even if you launch the local, EMS shortcut on the local server even then its a remote session.

Whether you use the Exchange Management Shell to administer a local server or administer a server across the country, remote Shell is used to perform the operation in Exchange 2013.When the remote session is created, you're given access only to the cmdlets and the parameters associated with the management role groups and management roles you're assigned.

This is what the shortcut says, if you would like to analyze:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell "

The Shell always connects to an Exchange 2010 server via an Internet Information Server (IIS) virtual directory, regardless of whether you're connecting to a local server or a server across the country. WinRM is the communication mechanism between your Shell session and the Exchange 2010 server.

I have to assume that you have a broken install which carries along with the updates as well. Try installing a fresh server to the environment and see if it behaves similarly.

You might give it a try to re-install .NET 4.5.2 (Note this is complicated and might break things)

References:

Missed one thing earlier, what happens if you create a new user and make it full administrator. Does that user also behave like your account or its like the adminstrator.

had created copy of Aleks - ALL works! What is wrong with Aleks?

Hi Anahaym,

Thanks for the update.

To find what's wrong, you need to dig in using my earlier posts and then further enabling logging at highest level, drill down the available clues.

I would say that is not required for isolated issues as this, consider your account to be corrupted(Why? read the second para for figuring it out).

At this point I would consider your issue being resolved here.

added to Administrators - same. Domain Admins and Enterprise Admins already exist.

ran:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell "

same.

have recreated Aleks profile - same.

Could you prease repeat what i should to do? i losted mind..........

Hi Anahaym,

To be on the point, you can backup the Aleks profile data, delete the account in AD and re-create it map the data , permissions back.

As at this point issue is only for one account, hence we would consider the account to be corrupted, there is no point in looking at it, if the issue is non-recurrent.