Archiv der Kategorie: Microsoft

Kalenderberechtigungen für eine Gruppe anzeigen

Exchange, , , ,

$groupmembers = Get-ADGroupMember -Identity Groupname
$result=@()
Foreach ($member in $groupmembers){
$user = get-aduser $member.samaccountname -Properties *
$sam = $member.samaccountname
$email = $user.EmailAddress
$name = $user.DisplayName
$right = Get-MailboxFolderPermission $email“:\Kalender“ -User Default -ErrorAction SilentlyContinue | select AccessRights
if ($right -eq $null){$right =  Get-MailboxFolderPermission $email“:\Calendar“ -User Default -ErrorAction SilentlyContinue | select AccessRights}
if ($right -eq $null){$right = „nix“}else{$right = $right.AccessRights[0]}
$exserver = $user.msExchHomeServerName
if ($exserver -eq $null){$exserver = „“}
$dings = new-Object PSObject -Property @{
user = $email
homeserver = $exserver
right = $right
sam = $sam
name = $name}
$result += $dings
}
$result | Out-GridView

Office 365 – Can’t sign in – Error 80041317 | Jack Stromberg

Office 365, , , , , ,

After a long conversation with Microsoft, the end result was somehow federation between Microsoft and our ADFS servers was severed. Here is how we fixed it.

Remote desktop to your ADFS server (not the proxy)

Open the Windows Azure Active Directory Module for Windows PowerShell as an administrator If you are old to ADFS, this was formerly called Microsoft Online Services Module

Execute the following command: Connect-MsolService Type in your Office 365 admin credentials. I highly recommend you use a cloud based user called youradmin@yourdomain.onmicrosoft.com in the case you cannot federate.

Execute the following command: Update-MsolFederatedDomain Type in the domain name you federate to office 365 (yourcompany.com). Successfully updated ‘yourdomain.com’ domain. message when done.

Execute the following command: convert-msoldomaintostandard -domainname mydomain.com -passwordfile pass.txt -skipuserconversion $true This command will break federation (essentially turn it off) to Office 365. This will not lose your mailboxes, settings, etc.

Execute the following command: Convert-MsolDomainToFederated This command will re-establish federation to Office 365

Execute the following command: Update-MsolFederatedDomain This command will update URLs or certificate information within AD FS and Office 365. Note: If you have multiple domain names being federated, please use the following command: Update-MSOLFederatedDomain -DomainName mydomain.com -supportmultipledomain

Next, I restarted my proxy server, reran the ADFS wizard to ensure the proxy could communicate to the primary ADFS server, and waited a minute or so.

At this point, authentication began to work properly again.

Quelle: Office 365 – Can’t sign in – Error 80041317 | Jack Stromberg

follow the message through Exchange logs

Exchange, , , , ,

you have to enable connecotor logs with verbose log level!

  1. find session id on receive in
    C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
    search recipient or sender….you will find also the message id!!!
  2. show all lines of this session
    @(Get-Content -Path „C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive\RECV20150429-1.LOG“) -match „08D24ED360CF3B98“ | Out-GridView
    see connector id, etc.
  3. find session id on send to hup
    C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend
    search by message id, recipient or sender…
  4. search session id in current log file of frontend send connectors
    @(Get-Content -Path „C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend\SEND20150429-1.LOG“) -match „08D24ED360CF3B98“ | Out-GridView

    do the same for following files

  5. C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive\RECV20150429-1.LOG
  6. C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend\SEND20150429-1.LOG
  7. C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive\Delivery\RECV20150429-1.LOG

set higher level of connector logs

Exchange, , , , ,

connector logs have a rollover for log files, so if you set a high level for logging, you may have a fewer time range, but more Information

Get-ReceiveConnector | Set-ReceiveConnector -ProtocolLoggingLevel Verbose
Get-TransportService | Set-TransportService -IntraOrgConnectorProtocolLoggingLevel verbose
Get-MailboxTransportService | Set-MailboxTransportService -MailboxDeliveryConnectorProtocolLoggingLevel Verbose

for Exchange 2013

Einen Client-Request in Exchange 2013 verfolgen

Exchange, , , ,

um einen Client-Request am Exchange-Server zu verfolgen

  • Welcher Server? wo kommt der request an?
    https://exchangehostname/mapi/emsmdb
    ping exchangehostname
  • HTTP-Log um die Request ID zu erlangen
    C:\inetpub\logs\LogFiles\W3SVC1 (W3SVC1 ist bei Multi-Role-Server der CAS, W3SVC2 ist der MBX – sieht man auch an der ID in der IIS Administration)
  • Abhängig vom Client-Typ sucht man nach dem Request (um den Verbindungstyp bei Outlook festzustellen, in der Taskleiste im „Notification area“ mit aktiver STRG-Taste ein Rechtsklick auf das Outlook-Symbol und den „Verbindungsstatus…“ anzeigen – bei Protokoll findet man nun den Verbingunstyp)
    für Outlook mit RPC/HTTP sucht man dann nach „/rpc“ oder auch bei ECP „/ViewUserMailboxDetails.aspx“
  • muss in Folge im richtigen HTTP-Proxy-Verzeichnis gesucht werden
    RCP via Outlook C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\RpcHttp
    ECP via Browser: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ecp
    hier findet man dann mit obiger ID auf welchen Exchange-Server man weitergeleitet wurde bzw. auch die Mailbox-ID etc.
  • auf dem Exchange-Server muss dann im Backend gesucht werden
    beginnend mit dem aktuellen IIS-Log: in C:\inetpub\logs\LogFiles\W3SVC2 nach obiger ID durchsuchen
  • in Folge die Exchange Backend Logs
    • RCP via Outlook C:\Program Files\Microsoft\Exchange Server\V15\Logging\RpcHttp\W3SVC2 (W3SVC wieder abhängig von der ID im IIS)
      • weiter im RCP Client Access-Log
        C:\Program Files\Microsoft\Exchange Server\V15\Logging\RPC Client Access
        hier finde ich ob der Logon funktioniert hat bzw. auch einen Access Denied oder ob der aktuelle User auch in der Rolle „Owner“ zugegriffen hat (=OwnerLogon) oder über eine Freigabe (=DelegateLogon)
    • MAPI via Outlook C:\Program Files\Microsoft\Exchange Server\V15\Logging\MAPI Client Access
    • ECP via Browser:
      • unter C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Activity findet man ob man angekommen ist
      • unter C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server findet man was gemacht wurde