none
Exchange 2013 startet Dienste nicht mehr RRS feed

  • Frage

  • Fehlerereignis:

    Prozess Microsoft.Exchange.Directory.TopologyService.exe (PID=2248). Der Exchange-Server DC.domain.local* verfügt über keine Berechtigung für die Sicherheitsüberwachung auf dem Domänencontroller DC.domain.local. Dieser Domänencontroller wird vom Exchange Active Directory-Anbieter nicht verwendet.

    Da wo hier ein Exchange-Server gemeint ist, steht in Wahrheit der Hostname aller Domänencontroller (je Meldung ein DC). Microsoft, bitte, was soll dieser Blödsinn????

    Ich stecke mit meinen Live-Erfahrungen am Exchange 2013 noch in den Kinderschuhen und finde nach weniger als 3 Stunden investiertem Administrationsaufwand solche Fehler!

    Die Auswirkungen: ca. 48h nach Abschluss des Setups stellt Exchange seinen Dienst ein. Der Neustart dauert danach statt 1 Minute ca. 20 Minuten. Minuten des Schwitzens, ob die Kiste je wieder erreichbar ist!

    Abhilfe:

    - GPO bauen und der OU Domänencontroller zuweisen

    - Inhalt der GPO: Computerkonfig... Lokale Sicherheitsrichtlinien "Verwalten von Überwachungs- und Sicherheitsprotokollen". Laut Microsoft'scher Fehlanleitung (!) sollten hier die Exchange-Server drinstehen. Das ist in sofern Quatsch, als dass es nichts ändert. Hier gehören die DCs rein. Folge: Exchange-Server samt Dienste startet wieder innerhalb 1 Minute (so wie vorher) und funktioniert wieder.

    Was mich stört, ist die fahrlässige Art und Weise von Microsoft, solch mangelhafte Produkte herauszugeben. Wie kann es sein, dass solche Dinge vor einem Release nicht auffallen? Man sollte doch meinen, Microsoft würde wenigstens einmal die fertige ISO mounten, einen Exchange starten und zuschauen, was nach 48 Stunden passiert.

    *Host und Domänenname geändert!

    Frage gilt als selbst gelöst.

    zweite Frage: was haben wir denn hier falsch gemacht?

    Event code: 3005

    Event message: Es ist eine unbehandelte Ausnahme aufgetreten.

    Event time: 30.11.2013 13:40:13

    Event time (UTC): 30.11.2013 12:40:13

    Event ID: f3afc7e47c03452c86239dbb0891ad5d

    Event sequence: 2

    Event occurrence: 1

    Event detail code: 0

    Application information:

        Application domain: /LM/W3SVC/2/ROOT/owa-1-130302881787705910

        Trust level: Full

        Application Virtual Path: /owa

        Application Path: C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa\

        Machine name: MAIL

    Process information:

        Process ID: 6508

        Process name: w3wp.exe

        Account name: NT-AUTORITÄT\SYSTEM

    Exception information:

        Exception type: ArgumentOutOfRangeException

        Exception message: The performance counter: "Current Unique Users" is not supported to be updated by method Globals.IncrementCurrentUsersCounterBy().

    Parametername: performanceCounter

       bei Microsoft.Exchange.Clients.Common.PerformanceCounterManager.IncrementCurrentUsersCounterBy(ExPerformanceCounter performanceCounter, Int64 incrementValue)

       bei Microsoft.Exchange.Clients.Common.PerformanceCounterManager.IncrementUserPerfCounters(String userName, Boolean isProxy, Boolean isLightExperience)

       bei Microsoft.Exchange.Clients.Common.PerformanceCounterManager.UpdatePerfCounteronUserContextCreation(String userName, Boolean isProxy, Boolean isLightExperience, Boolean arePerfCountersEnabled)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.UserContextManager.CreateUserContext(HttpContext httpContext, UserContextKey userContextKey, ClientSecurityContext overrideClientSecurityContext, UserContext& userContext)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.UserContextManager.AquireUserContext(HttpContext httpContext, ClientSecurityContext overrideClientSecurityContext)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.UserContextManager.GetUserContext(HttpContext httpContext, Boolean create)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.RequestDispatcher.InternalDispatchRequest(RequestContext requestContext)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.RequestDispatcher.DispatchRequest(RequestContext requestContext)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.OwaRequestHandler.OnPostAuthorizeRequest(Object sender, EventArgs e)

       bei System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

       bei System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

    Request information:

        Request URL: https://localhost:444/owa/proxylogon.owa

        Request path: /owa/proxylogon.owa

        User host address: ::1

        User: BLOGHUETTE\SM_b7081575b221445eb

        Is authenticated: True

        Authentication Type: Kerberos

        Thread account name: NT-AUTORITÄT\SYSTEM

    Thread information:

        Thread ID: 15

        Thread account name: NT-AUTORITÄT\SYSTEM

        Is impersonating: False

        Stack trace:    bei Microsoft.Exchange.Clients.Common.PerformanceCounterManager.IncrementCurrentUsersCounterBy(ExPerformanceCounter performanceCounter, Int64 incrementValue)

       bei Microsoft.Exchange.Clients.Common.PerformanceCounterManager.IncrementUserPerfCounters(String userName, Boolean isProxy, Boolean isLightExperience)

       bei Microsoft.Exchange.Clients.Common.PerformanceCounterManager.UpdatePerfCounteronUserContextCreation(String userName, Boolean isProxy, Boolean isLightExperience, Boolean arePerfCountersEnabled)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.UserContextManager.CreateUserContext(HttpContext httpContext, UserContextKey userContextKey, ClientSecurityContext overrideClientSecurityContext, UserContext& userContext)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.UserContextManager.AquireUserContext(HttpContext httpContext, ClientSecurityContext overrideClientSecurityContext)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.UserContextManager.GetUserContext(HttpContext httpContext, Boolean create)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.RequestDispatcher.InternalDispatchRequest(RequestContext requestContext)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.RequestDispatcher.DispatchRequest(RequestContext requestContext)

       bei Microsoft.Exchange.Clients.Owa2.Server.Core.OwaRequestHandler.OnPostAuthorizeRequest(Object sender, EventArgs e)

       bei System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

       bei System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

    Custom event details:


    vg schwippschwapp


    • Bearbeitet Tocsin 2015 Samstag, 30. November 2013 12:51 unbehandelter reason!
    Samstag, 30. November 2013 12:30

Alle Antworten

  • Zu dem ersten Problem:

    In allen meinen Installationen stehen in der Policy "Manage auditing and security log" die Gruppen Administrators, Exchange Servers und Exchange Enterprise Servers. Scheint also bei dir ein Fehler zu sein.

    Zu dem zweiten Problem:

    KA, aber irgendwelche Performance Counter Fehler habe ich auch laufend :(

    Montag, 2. Dezember 2013 08:06
  • Hallo schwippschwapp,

    anstatt Dich in der Meldung an Microsoft auszulassen, solltest Du erst einmal Deine Umgebung inkl. der eingesetzten Software und Updates erläutern!

    Gruß

    Dominik

    Montag, 2. Dezember 2013 12:49
  • Zu dem ersten Problem:

    In allen meinen Installationen stehen in der Policy "Manage auditing and security log" die Gruppen Administrators, Exchange Servers und Exchange Enterprise Servers. Scheint also bei dir ein Fehler zu sein.

    Zu dem zweiten Problem:

    KA, aber irgendwelche Performance Counter Fehler habe ich auch laufend :(

    und die DCs?

    Und wieso lautet die Fehlermeldung, dass der Exchangeserver mit dem Namen "--hier standen die Namen aller DCs---" nicht eingetragen ist?

    Wie kommt denn Exchange-Server auf die Idee, dass meine 3 DCs jeweils Exchange-Server sind?

    vg schwippschwapp

    Montag, 2. Dezember 2013 12:53
  • Hallo schwippschwapp,

    anstatt Dich in der Meldung an Microsoft auszulassen, solltest Du erst einmal Deine Umgebung inkl. der eingesetzten Software und Updates erläutern!

    Gruß

    Dominik

    2 DCs 2k8r2
    1 DC 2k12r2
    1 Ex 13 auf 2012 R1 Member

    alle aktuellen Servicepacks und Patches drauf, außer das CU2 für Exchange, welches lt. diverser Foren viele Probleme bereitet, die es vorher nicht gab. Beim Exchange bin ich immer vorsichtig und warte ca. 4-8 Wochen, in dieser Zeit durchforste ich die Foren nach auftretenden Problemen (Betatesten kann ich mir in den Umgebungen nicht leisten) und entscheide dann über das Update-Risiko.

    vg schwippschwapp



    • Bearbeitet Tocsin 2015 Montag, 2. Dezember 2013 12:58 Anpassungen
    Montag, 2. Dezember 2013 12:56
  • Du solltest erstmal ALLE Exchange Server auf CU3 updaten, um hier weitermachen zu können ...
    Montag, 2. Dezember 2013 13:05
  • Es gibt nur einen exchange. Cu3 ist also problemlos einzuspielen und verursacht keine unangenehmen Nebenwirkungen?
    Montag, 2. Dezember 2013 13:13
  • CU3 hat deutlich viele Verbesserungen bekommen und sollte zwingend eingespielt werden. CU3 hatte ein lange Testphase hinter sich, auch ich habe jegliche Vorversionen im Lab getestet.  Ausschließen kann man "unangenehme Nebenwirkungen" nie, da jeder ein anderes Benutzerverhalten und andere Umgebungen aufweist.

    Ich würde dir es jedoch dringend empfehlen, CU3 einzuspielen. Die vielen Verbesserungen zahlen sich aus! Ansonsten kann zumindest ich dir bei dem Problem nicht mehr weiterhelfen, da CU1 schon eine Zeit lang zurück liegt.

    Gruß

    Dominik

    Montag, 2. Dezember 2013 13:29
  • geniale Idee, wirklich klasse!

    powershell set-execution auf unrestricted gesetzt wie es sich gehört, Überprüfung alles ok, Ausführung endet dann mit Fehler im Schritt 5. Dienste sind beendet.

    Es ist herrlich mit anzusehen, wie erfolgreich Microsoft's Vorabtests sind, diese sind einen Schrott wert! Sorry, aber dieser Exchange STEHT KOMPLETT!

    HERVORRAGENDER CU3!!!

    Nachtrag Fehlermeldung - kann man ja leicht durch erneutes ausführen bekommen:

    Fehler:

    Der folgende Fehler wurde generiert, als "$error.Clear();

                        & $RoleBinPath\ServiceControl.ps1 EnableServices Critical

                    " ausgeführt wurde: "Fehler bei der AuthorizationManager-Überprüfung.".


    ----

    http://social.technet.microsoft.com/Forums/exchange/de-DE/fe02fd5f-8398-4af9-ad82-f240c7f0a178/exchange-2013-cu2-will-not-install-exchange-is-now-in-an-unuseable-state

    -> die darin anscheinen hilfreichen Tricks kann ich nicht mehr ausführen, da die powershell nicht mehr funktioniert

    -> Dienste manuell umstellen und starten bringt keine Verbesserung der Situation, Setup bricht genauso ab.

    Die große Frage: in welchem Zustand ist der Exchange jetzt? Darf ich alle Dienste wieder auf Autostart setzen und ausführen?

    • Bearbeitet Tocsin 2015 Montag, 2. Dezember 2013 18:23 skldjfljoewrituw
    Montag, 2. Dezember 2013 18:02
  • Welche Antwort erwartest du nun in diesem Forum? Du solltest dir jemanden holen, der sich mit 2013 auskennt! Sende bitte die Fehlermeldung ... Irgendwo ist im AD oder bei der Erstinstallation der Wurm drin. Du schiebst die Schuld nur weiter, anstatt vernünftige Posts mit allen Informationen zu bringen. SetupLog sollte Klarheit schaffen, was genau schiefgelaufen ist. Mehr kann ich dazu nicht mehr sagen ... Nur weil es in deiner Umgebung nicht funktioniert!
    Montag, 2. Dezember 2013 18:08
  • Die Fehlermeldung steht da bereits...

    Also nochmal:

    Der folgende Fehler wurde generiert, als "$error.Clear();

                        & $RoleBinPath\ServiceControl.ps1 EnableServices Critical

                    " ausgeführt wurde: "Fehler bei der AuthorizationManager-Überprüfung.".

    ---

    lt Log ist dies das letzte was gemacht wird:

    # Standardmäßig Start Schritte für MidFileCopy.
    # Programmgesteuert generiert auf 02.12.2013 19:40:56.

    #
    # Variablendeklarationen
    #
    $RoleBinPath = 'C:\Windows\Temp\ExchangeSetup'
    $RoleDatacenterPath = 'C:\Windows\Temp\ExchangeSetup\Datacenter'
    $RoleDatacenterServiceEndpointABCHContactService = '<ServiceEndpoint><Url>http://pvt-contacts.msn.com/abservice/abservice.asmx</Url></ServiceEndpoint>'
    $RoleDatacenterServiceEndpointDomainPartnerManageDelegation = '<ServiceEndpoint><Url>https://domains.live.com/service/managedelegation.asmx</Url></ServiceEndpoint>'
    $RoleDatacenterServiceEndpointDomainPartnerManageDelegation2 = '<ServiceEndpoint><Url>https://domains.live.com/service/managedelegation2.asmx</Url></ServiceEndpoint>'
    $RoleDatacenterServiceEndpointLiveFederationMetadata = '<ServiceEndpoint><Url>https://nexus.passport.com/FederationMetadata/2006-12/FederationMetadata.xml</Url></ServiceEndpoint>'
    $RoleDatacenterServiceEndpointLiveGetUserRealm = '<ServiceEndpoint><Url>https://login.live.com/GetUserRealm.srf</Url></ServiceEndpoint>'
    $RoleDatacenterServiceEndpointLiveServiceLogin2 = '<ServiceEndpoint><Url>https://login.live.com/RST2.srf</Url></ServiceEndpoint>'
    $RoleDatacenterServiceEndpointMsoFederationMetadata = '<ServiceEndpoint><Url>https://nexus.microsoftonline-p.com/FederationMetadata/2006-12/FederationMetadata.xml</Url></ServiceEndpoint>'
    $RoleInstallationMode = 'BuildToBuildUpgrade'
    $RoleInstallPath = 'C:\Windows\Temp\ExchangeSetup'
    $RoleInvocationID = '20131202-1940560129662664452'
    $RoleIsDatacenter = $False
    $RoleIsDatacenterDedicated = $False
    $RoleIsFfo = $False
    $RoleIsPartnerHosted = $False
    $RoleLoggingPath = 'C:\Windows\Temp\ExchangeSetup\Logging'
    $RolePreviousVersion = '15.00.0516.032'
    $RoleProductPlatform = 'amd64'
    $RoleRoles = 'BridgeheadRole,FrontendTransportRole,ClientAccessRole,UnifiedMessagingRole,MailboxRole,AdminToolsRole,CafeRole'
    $RoleSetupLoggingPath = 'C:\ExchangeSetupLogs'
    $RoleTargetVersion = '15.00.0775.038'

    #
    # Komponententasks
    #

    # Tasks für Komponente 'All Roles MidFileCopy'
    # [ID = AllRolesMidFileCopyComponent___a246d37d6b1140b8a32d2564949752be, Wt = 1, isFatal = True] "Dateien werden für alle Rollen vorbereitet"
    02.12.2013 19:40:56:
                      $setupRegKeyPath = "HKLM:\Software\Microsoft\ExchangeServer\v15\setup"
                      if (-not (Test-Path $setupRegKeyPath))
                      {
                          # During upgrade, setup key may not exist during mid-file copy stage since older MSI might have been uninstalled
                          # So, we read the reg key from backed up path.
                          $setupRegKeyPath = "HKLM:\Software\Microsoft\ExchangeServer\v15\setup-save"
                      }
                      $RoleInstallPath = (Get-ItemProperty $setupRegKeyPath).MsiInstallPath
                   if ($RoleInstallPath -ne $null)
                   {
                        Get-ChildItem $RoleInstallPath -Recurse -Include "*.dll","*.exe" |
                        %{$_.FullName} |
                        %{
                            $originalPath = $_;
                            $pathToDelete = "$originalPath.$([Guid]::NewGuid())";

                            Move-Item  $originalPath $pathToDelete -Force -ErrorAction SilentlyContinue;
                            if (Test-Path $originalPath) {$pathToDelete = $originalPath}

                            $domain = [AppDomain]::CurrentDomain;
                            $name = New-Object Reflection.AssemblyName 'DynamicAssembly';
                            $assembly = $domain.DefineDynamicAssembly($name, 'Run');
                            $module = $assembly.DefineDynamicModule('DynamicModule');
                            $type = $module.DefineType('DynamicType');

                            [Type[]]$parameterTypes = [string], [string], [int64];
                            $method = $type.DefineMethod("MoveFileEx", 'Public,Static,PinvokeImpl', [bool], $parameterTypes) ;

                            $ctor = [Runtime.InteropServices.DllImportAttribute].GetConstructor([string]);
                            $attr = New-Object Reflection.Emit.CustomAttributeBuilder $ctor, 'kernel32';
                            $method.SetCustomAttribute($attr) ;
                            $realType = $type.CreateType() ;
                            [object[]]$args = [string]$pathToDelete, $null, [int64]4;
                            $realType.InvokeMember('MoveFileEx', 'Public,Static,InvokeMethod', $null,$null, $args) ;
                        }
                      }
                   
    # [ID = AllRolesMidFileCopyComponent___af0f15afe35c4e7cba121e546f405214, Wt = 1, isFatal = True] "Dateien werden für alle Rollen vorbereitet"
    02.12.2013 19:40:56:
                        & $RoleBinPath\ServiceControl.ps1 EnableServices Critical

    Montag, 2. Dezember 2013 18:44
  • Welche Antwort erwartest du nun in diesem Forum? Du solltest dir jemanden holen, der sich mit 2013 auskennt! Sende bitte die Fehlermeldung ... Irgendwo ist im AD oder bei der Erstinstallation der Wurm drin. Du schiebst die Schuld nur weiter, anstatt vernünftige Posts mit allen Informationen zu bringen. SetupLog sollte Klarheit schaffen, was genau schiefgelaufen ist. Mehr kann ich dazu nicht mehr sagen ... Nur weil es in deiner Umgebung nicht funktioniert!

    Lt. folgendem Eintrag bin ich wohl nicht der einzige, wenngleich der das Problem mit CU2 hat:

    http://social.technet.microsoft.com/Forums/exchange/de-DE/fe02fd5f-8398-4af9-ad82-f240c7f0a178/exchange-2013-cu2-will-not-install-exchange-is-now-in-an-unuseable-state

    Anscheinend werden hier beim Setup 4 Dienste gestoppt, die eigentlich gebraucht werden. Es wäre hilfreich, wenn jemand beobachten könnte, ob das bei ihm genauso passiert. Mein AD ist sicher nicht schuld, dass das Setup die Dienste stoppt. Das SETUP beendet ja die Dienste.

    Montag, 2. Dezember 2013 18:47
  • ein manuelles Ausführen dieses Skripts:

    ServiceControl.ps1 EnableServices Critical

    bringt ein hübsches rotes Powershell-Ergebnis:

    PS C:\windows\temp\ExchangeSetup> .\ServiceControl.ps1 EnableServices Critical
    .\ServiceControl.ps1 : Fehler bei der AuthorizationManager-Überprüfung.
    In Zeile:1 Zeichen:1
    + .\ServiceControl.ps1 EnableServices Critical
    + ~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : Sicherheitsfehler: (:) [], PSSecurityException
        + FullyQualifiedErrorId : UnauthorizedAccess

    ---

    die Frage ist nun, warum unauthorizedaccess? Wie kann ich ermitteln, woran das jetzt liegt?

    Ich bin als Domänenadministrator angemeldet und führe die powershell bereits "als admin" aus. Gibt es nochwas zu beachten? Brauche ich speziell Rollen-Zuweisungen?

    ...btw auch wenn das nicht so rüberkommen mag, meine Nerven liegen blank, aber ich bin für jeden Hinweis wirklich dankbar und bringe gerne vor, was weiterhilft.

    Montag, 2. Dezember 2013 18:54
  • War in dem gleichen AD vorher ein Exchange 2010 oder wurde für 2013 ein "frisches" AD aufgesetzt?

    Bitte die GPO-Settings und die ExecutionPolicy wieder auf Default setzen; das hat in deinem Fall nichts mit CU3 zu tun.

    Das Schema-Update lief ohne Probleme durch?

    Wenn ja, bitte die beiden Einstellungen auf Default setzen und die Installation noch einmal starten. Wenn du das Schema-Update bereits gemacht hast, reicht die RBAC-Rolle der Domänen-Admins um Exchange zu installieren.

    Montag, 2. Dezember 2013 19:02
  • also, während des Setups wird auch winmgmt gestoppt. Solange dieser Dienst läuft, kann ich den Befehl

    ServiceControl.ps1 EnableServices Critical

    noch händisch ausführen. Sobald der Dienst stoppt, kann ich den Befehl nicht mehr ausführen.

    D.h. im Klartext, das Setup hat hier einen gewaltigen Bug!

    Wie auch immer, die Dienste lassen sich klarerweise nicht mehr starten, der Exchange-Server ist erstmal ruiniert.

    Montag, 2. Dezember 2013 19:12
  • Falls meine o.g. Schritte nicht funktionieren, ist wohl die einzige Möglichkeit, den Server zu recovern (Setup /m recoverserver). Aber bitte mit aktuellem CU3.

    Ist es denn ein "frisches" AD?

    Das Setup hat keinen Bug; das einfach zu behaupten ohne den Grund zu kennen, ist nicht sehr hilfreich, vor allem für andere User in diesem Forum! CU3 lief bei weit über 20 Installationen fehlerfrei - sowohl Upgrade als auch Neuinstallationen.

    Montag, 2. Dezember 2013 19:16
  • ja, es gab einen 2010er. Der wurde entfernt, dann wurde eine Zeit lang eine cloud-Lösung benutzt, jetzt sollte wieder ein lokaler Server den Dienst aufnehmen.

    Schema-Update lief durch, zumindest wurde nichts beanstandet.

    Welche BEIDEN Einstellungen meinst Du? Die exec-policy und was noch?

    Zurzeit spiele ich das Voll-Backup der letzten Nacht ein (per Windows-Sicherung, Systemstate).

    Ich hoffe, das reicht um wenigstens den gestrigen Stand wieder herzustellen.

    Sobald fertig, gebe ich Info.

    Montag, 2. Dezember 2013 19:26
  • das AD ist ca. 4 Jahre alt.

    Wenn ich diesen einen Thread mit einem eindeutigen Hinweis, wie ich den jetzt gegeben habe, gefunden hätte, hätte das CU3 bleiben können, wo es ist. Ich denke es wird tausende geben, die zumindest vorsichtiger sind bei dem was sie tun. Ich war's nicht - muss ich zugeben.

    Eines ist doch unbestritten: Die Vortests laufen einwandfrei, dann werden alle Dateien gelöscht, Dienste gestoppt, und dann kommt das Setup drauf "Scheiße, ich kann ja garnicht weitermachen"... In meinen Augen mehr als fahrlässig programmiert. Soetwas darf nicht passieren. Ok, den Punkt der Diskussion möchte ich nicht weiter ausführen.

    Das Restore ist zu 40% durch.

    Montag, 2. Dezember 2013 19:31
  • Da ist auch das Problem: der 2010er wurde nicht vollständig/korrekt deinstalliert! Die Fehlermeldungen gab es ausschließlich bei 2010 SP2, so weit wie ich mich zurückerinnern kann.

    Das hat nichts mit dem Exchange 2013 zu tun, warum: der Authorization Manager ist eine Windows Server Komponente und diese speichert seine Informationen im AD.

    Authorization Manager provides a flexible framework for integrating role-based access control into applications. It enables administrators who use those applications to provide access through assigned user roles that relate to job functions.

    Das wird dich nicht sehr erfreuen: Exchange 2013 CU3 resolves an issue where backups may not restore.

    http://blogs.technet.com/b/rmilne/archive/2013/11/25/exchange-2013-rtm-cu3-released.aspx

    Hier kann leider keiner "mehr" für dich tun, da es KEIN Exchange Problem ist. Ich kann dir das auch gerne von Microsoft direkt bestätigen lassen.

    Gruß

    Dominik

    Montag, 2. Dezember 2013 19:33
  • R.I.P. schwippschwapp...

    Montag, 2. Dezember 2013 19:42
  • Restore hat den Programmordner nicht wieder hergestellt.

    /m:recoverserver ist ein ungültiger Parameter.


    • Bearbeitet Tocsin 2015 Montag, 2. Dezember 2013 19:56 Tippfehler korrigiert
    Montag, 2. Dezember 2013 19:55
  • Restore vom Windows-Backup / Backup-Programm?

    Oder dieser hier: Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms

    Montag, 2. Dezember 2013 19:57
  • Restore vom Windows-Backup hat nicht alles wieder hergestellt.

    /m:recoverserver hat dann doch mal gestartet (der iaccept... war klar, hing dran). Ursache: copy/paste. Manuell eingetippt geht's.

    /m:recoverserver bricht aber sofort ab, weil ja schon alles installiert ist. Meldung:

    [12.02.2013 19:57:09.0978] [0] The server cannot be recovered because Setup has detected that Exchange server roles are already installed.
    [12.02.2013 19:57:10.0056] [0] [ERROR] Die folgenden Serverrollen sind bereits installiert: BridgeheadRole, ClientAccessRole, MailboxRole, UnifiedMessagingRole, FrontendTransportRole, AdminToolsRole, CafeRole.
    [12.02.2013 19:57:10.0071] [0] Setup von Exchange Server wurde nicht abgeschlossen. Weitere Details finden Sie im Protokoll 'ExchangeSetup.log' im Ordner '<SystemDrive>:\ExchangeSetupLogs'.
    [12.02.2013 19:57:10.0087] [0] End of Setup
    [12.02.2013 19:57:10.0087] [0] **********************************************

    ok, auf der gleichen Maschine wird das wohl nix, brauche also eine "neue".

    http://technet.microsoft.com/de-de/library/dd876880(v=exchg.150).aspx

    • Bearbeitet Tocsin 2015 Montag, 2. Dezember 2013 20:04 sdfsdf
    Montag, 2. Dezember 2013 20:00
  • Sorry, klar dass das nicht geht.

    http://mouzzamh.wordpress.com/2013/03/05/recovering-a-failed-exchange-2013-server/

    Auf eigene Verantwortung ... Ich kann dir hier an dieser Stelle leider nicht mehr weiterhelfen. Du wirst auch in Zukunft bei Updates / Installationen Probleme haben, da irgendwo noch kleine Reste im AD von der 2010er Version sind.

    Trotz allem, viel Erfolg

    Montag, 2. Dezember 2013 20:05
  • tja, das war's. Restore schlägt fehl, recover schlägt fehl... Kunde steht die nächsten Tage ohne Exchange da.

    Schäden sind vorprogrammiert!

    Von Microsoft wird keine Hilfe zu bekommen sein, die werden 152 Tausend einzelne Support-Cases öffnen wollen.

    Danke für Deine Hilfe. Wenn gleich ich mir gerade wünsche, ich hätte diesen Thread nie eröffnet. Im Endergebnis habe ich großen Schaden verursacht, das hätte nicht sein müssen.

    Ich werde dem Kunden morgen empfehlen, auf Google Mail zu wechseln, sobald wir die Mails aus den Cache-Dateien aller Outlook-Version exportiert haben.

    Montag, 2. Dezember 2013 20:14
  • So, ich kann Erfolg vermelden, Exchange rennt wieder. Ich habe das CU3 durchgeprügelt.

    Was war passiert?

    1.) Eine Ursache ist die "falsche" execution policy. Weil Microsoft scheinbar unfähig ist, seine eigenen scripts so zu signieren dass ihre hochsichere powershell sie auch ausführt, muss man das umstellen. Soweit kein Problem, es sei denn man macht das per GPO. Stoppt aber der wmi Dienst erstmal, schlägt die Überprüfung der Berechtigung auf die GPO fehl, dazu wird wmi ja benötigt. Also: GPOs abdrehen (egal wie sie eingestellt sind, es kommt darauf an, DASS sie auf "nicht konfiguriert" eingestellt sind. gupdate nicht vergessen. Dann die execution policy umstellen auf unsigned (damit wir auch Microsoft-code ausführen können :-P)

    2.) Nun findet das Setup einen Registry key nicht mehr. Evtl. wurde der beim ersten Update-Versuch schon gelöscht. Update bricht wieder ab. Maßnahme: cmd als admin ausführen und folgenden Befehle abschicken:

    $env:CERES_REGISTRY_PRODUCT_NAME = "Search Foundation for Exchange"

    3.) Im nächsten Anlauf wird dann erkannt, dass wir schon eine push-Webseite haben und bricht ab. Gegenmaßnahme ist hier, den Unterbaum einfach im IIS löschen: /pushnotifications

    4.) Ich hab dann das Setup laufen lassen und die RDP-Verbindung getrennt. Am heutigen Morgen war vom Update-Fenster nichts mehr zu sehen, ein paar Dienste liefen, viele nicht, ließen sich aber alle manuell starten.

    Was mich hier stört, ist, dass das Update extrem empfindlich ist und man als admin weder gescheite Gesamtanleitungen mit ALLEN Voraussetzungen findet (jedenfalls nicht über Google, mit bing ja schon grad garnicht), noch, dass das Vorabüberprüfungstool nicht im Ansatz die notwendigen Voraussetzungen prüft und/oder findet. Das leitet den admin in die Irre und zurück auf den Boden der Tatsachen, nämlich, dass du am besten alles selbst testest und einstellst.

    Mit einem unsauberen AD hatte dieses Update meiner Ansicht nach nichts zu tun, auch nicht mit einer unsauber-geglaubten Deinstallation eines Ex2010.

    Der Gipfel (...) seitens Microsoft ist jedoch, dass sich Exchange 2013 nachweislich mit der Windows 2012 Sicherung nicht in der Form sichern und wieder herstellen lässt, dass es anschließend wieder funktioniert. Mag ja sein, dass man bei Microsoft nur mehr in Clustern und DAGs denkt, aber nicht jedes KMU hat 10 Server für 5 Postfächer! An die wurde wieder mal nicht gedacht. Liebe Microsoftler, AUCH DIESE KUNDEN BEZAHLEN EUCH!

    Ich werde hier noch testen, ob das CU3 diesen Punkt verbessert.

    Interessant ist, dass ich nur mithilfe von Blogeinträgen fleißiger Leute weiter kam. Auf Microsoft-Seiten habe ich zu den Problemen keine Lösungen finden können.

    vg

    Mittwoch, 4. Dezember 2013 09:09
  • So, ich kann Erfolg vermelden, Exchange rennt wieder. Ich habe das CU3 durchgeprügelt.

    Was war passiert?

    1.) Eine Ursache ist die "falsche" execution policy. Weil Microsoft scheinbar unfähig ist, seine eigenen scripts so zu signieren dass ihre hochsichere powershell sie auch ausführt, muss man das umstellen. Soweit kein Problem, es sei denn man macht das per GPO. Stoppt aber der wmi Dienst erstmal, schlägt die Überprüfung der Berechtigung auf die GPO fehl, dazu wird wmi ja benötigt. Also: GPOs abdrehen (egal wie sie eingestellt sind, es kommt darauf an, DASS sie auf "nicht konfiguriert" eingestellt sind. gupdate nicht vergessen. Dann die execution policy umstellen auf unsigned (damit wir auch Microsoft-code ausführen können :-P)

    2.) Nun findet das Setup einen Registry key nicht mehr. Evtl. wurde der beim ersten Update-Versuch schon gelöscht. Update bricht wieder ab. Maßnahme: cmd als admin ausführen und folgenden Befehle abschicken:

    $env:CERES_REGISTRY_PRODUCT_NAME = "Search Foundation for Exchange"

    3.) Im nächsten Anlauf wird dann erkannt, dass wir schon eine push-Webseite haben und bricht ab. Gegenmaßnahme ist hier, den Unterbaum einfach im IIS löschen: /pushnotifications

    4.) Ich hab dann das Setup laufen lassen und die RDP-Verbindung getrennt. Am heutigen Morgen war vom Update-Fenster nichts mehr zu sehen, ein paar Dienste liefen, viele nicht, ließen sich aber alle manuell starten.

    Was mich hier stört, ist, dass das Update extrem empfindlich ist und man als admin weder gescheite Gesamtanleitungen mit ALLEN Voraussetzungen findet (jedenfalls nicht über Google, mit bing ja schon grad garnicht), noch, dass das Vorabüberprüfungstool nicht im Ansatz die notwendigen Voraussetzungen prüft und/oder findet. Das leitet den admin in die Irre und zurück auf den Boden der Tatsachen, nämlich, dass du am besten alles selbst testest und einstellst.

    Mit einem unsauberen AD hatte dieses Update meiner Ansicht nach nichts zu tun, auch nicht mit einer unsauber-geglaubten Deinstallation eines Ex2010.

    Der Gipfel (...) seitens Microsoft ist jedoch, dass sich Exchange 2013 nachweislich mit der Windows 2012 Sicherung nicht in der Form sichern und wieder herstellen lässt, dass es anschließend wieder funktioniert. Mag ja sein, dass man bei Microsoft nur mehr in Clustern und DAGs denkt, aber nicht jedes KMU hat 10 Server für 5 Postfächer! An die wurde wieder mal nicht gedacht. Liebe Microsoftler, AUCH DIESE KUNDEN BEZAHLEN EUCH!

    Ich werde hier noch testen, ob das CU3 diesen Punkt verbessert.

    Interessant ist, dass ich nur mithilfe von Blogeinträgen fleißiger Leute weiter kam. Auf Microsoft-Seiten habe ich zu den Problemen keine Lösungen finden können.

    vg

    First check the event id 4999 and 137 in the application log, If we are getting these events then follow below action plan.

    1 - Take the IIS backup by running the command (%windir%\system32\inetsrv\appcmd.exe add backup backupname)
    2 - Run Remove-OwaVirtualDirectory -Identity "Servername\OWA (Exchange Back End)"
    3 - Perform IIS reset and ensure that in IIS under Exchange Back End website we dont have OWA virtual directory anymore.
    4 - Now run New-OwaVirtualDirectory -SERVER "Servername" -WebSiteName "Exchange Back End" -role:mailbox
    5 - Perform IIS reset
    6- In RTM version we have and issue that is after recreating OWA VD under Exchange Back End website it enables

    FormsAuthenticatio, So to enable correct auth follow KB http://support.microsoft.com/kb/2778897
    7 - Perform IIS reset.


    Mittwoch, 14. Mai 2014 03:37