dr_wahnsinnig

Die Zertifikatsmeldung kommt auch bei autodiscover.<domain>.<tld> und mail.<domain>.<tld> Ich komme aber halt auf die Login Maske.

Ja, Outlook Anywhere ist konfiguriert, wird aber zurzeit nicht genutzt.

Ich bekomme jedes Mal die Login-Site vom OWA. Get-ExchangeCertificate | fl CertificateDomains, Issuer, Subject, Not*, Services, Status ergibt: [PS] C:\Windows\system32>Get-ExchangeCertificate | fl CertificateDomains, Issuer, Subject, Not*, Services, Status CertificateDomains : {mobil.kundendomain.de} Issuer : CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US Subject : CN=mobil.kundendomain.de NotAfter : 18.10.2018 13:25:26 NotBefore : 20.07.2018 13:25:26 Services : IMAP, POP, IIS, SMTP Status : Valid

Hi Jan, das Zertifikat hat alle Dienste und ist mittlerweile auch das einzig verbliebene im Exchange. Ja, im Outlook wird das korrekte Zertifikat angezeigt. Mit dem Browser komme ich ohne Zertifikatswarnung mit dem grünen Schloss auf den OWA Login und kann mich auch anmelden. Smartphones können sich ebenfalls ohne Warnung anmelden. Den Exchange Server und die Terminalserver habe ich heute Morgen bereits einmal neu gestartet. Die letzten Updates für Exchange und Windows sind drin. Ich habe nun auch noch einmal ein zweites Augenpaar drüber schauen lassen - kein Fehler gefunden - Ich flipp aus

Hi, leider meckert jedes Outlook. Profile wurden ebenfalls vereinzelt komplett neu eingerichtet - ohne Erfolg.

Hi Joachim, der Test zeigt den Server "exchange-srv.domain.local". Dies zeigt auch der Test auf dem anderen Exchange Servers des anderen Kunden, bei dem diese Zertifikatsmeldung eben nicht erscheint. Ansonsten steht hier bei der internen und externen URL für Web Access mobil.kundendomain.de Ich schaue mir Deinen Link einmal an. Diese Anleitung bin ich gestern auch schon einmal durchgegangen. Sehr gut beschrieben - dennoch habe ich diese blöde Meldung vom Outlook. Danke schon mal! Gruß Andy

Hi liebes Forum, ich habe hier einen Exchange 2010 Server, der ein öffentliches Zertifikat bekommen hat. Damit Outlook nun nicht ständig meckert, dass der Name des Servers - Interner Name des Exchange Servers: exchange-srv.domain.local Externer Name: mobil.kundendomain.de nicht übereinstimmt, habe ich den Exchange Server so konfiguriert, dass die internen und externen URLs identisch sind. Auf dem AD habe ich Zonen für - mobil.kundendomain.de - mail.kundendomain.de - autodiscover.kundendomain.de eingerichtet, die alle auf die exchange-srv IP zeigen. Das öffentliche Zertifikat ist ausgestellt auf mobil.kundendomain.de. Outlook im lokalem Netzwerk bemängelt aber immer noch, dass der Name im Zertifikat nicht mit dem Namen des Server übereinstimmt. Die Verbindung wird immer noch über exchange-srv.domain.local hergestellt... Hier noch meine Konfig bezüglich der Verzeichnisse: [PS] C:\Windows\system32>get-AutodiscoverVirtualDirectory | fl RunspaceId : e9bb87e4-59a9-4145-8e95-41764b93c5e1 Name : Autodiscover (Default Web Site) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} LiveIdSpNegoAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True MetabasePath : IIS://exchange-srv.domain.local/W3SVC/1/ROOT/Autodiscover Path : D:\Exchange2010\ClientAccess\Autodiscover ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} Server : exchange-srv InternalUrl : ExternalUrl : AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) DistinguishedName : CN=Autodiscover (Default Web Site),CN=HTTP,CN=Protocols,CN=exchange-srv,CN=Servers, CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Horizo nte,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local Identity : exchange-srv\Autodiscover (Default Web Site) Guid : 3c54a8ba-5d52-480a-997a-4eba6df251b1 ObjectCategory : domain.local/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory} WhenChanged : 29.07.2013 19:22:23 WhenCreated : 29.07.2013 19:22:23 WhenChangedUTC : 29.07.2013 17:22:23 WhenCreatedUTC : 29.07.2013 17:22:23 OrganizationId : OriginatingServer : ad-srv.domain.local IsValid : True [PS] C:\Windows\system32>get-ClientAccessServer | fl RunspaceId : e9bb87e4-59a9-4145-8e95-41764b93c5e1 Name : exchange-srv Fqdn : exchange-srv.domain.local OutlookAnywhereEnabled : True AutoDiscoverServiceCN : exchange-srv AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service AutoDiscoverServiceInternalUri : https://mobil.kundendomain.de/autodiscover/autodiscover.xml AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596 AutoDiscoverSiteScope : {Default-First-Site-Name} AlternateServiceAccountConfiguration : IrmLogEnabled : True IrmLogMaxAge : 30.00:00:00 IrmLogMaxDirectorySize : 250 MB (262,144,000 bytes) IrmLogMaxFileSize : 10 MB (10,485,760 bytes) IrmLogPath : D:\Exchange2010\Logging\IRMLogs IsOutOfService : False MigrationLogLoggingLevel : Information MigrationLogFilePath : MigrationLogMaxAge : 180.00:00:00 MigrationLogMaxDirectorySize : 10 GB (10,737,418,240 bytes) MigrationLogMaxFileSize : 100 MB (104,857,600 bytes) IsValid : True ExchangeVersion : 0.1 (8.0.535.0) DistinguishedName : CN=exchange-srv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Administrative Groups,CN=domain,CN=Microsoft Exchange,CN=Services,CN=Confi guration,DC=domain,DC=local Identity : exchange-srv Guid : b416033c-06c9-4bc2-8b8c-d18450a1e290 ObjectCategory : domain.local/Configuration/Schema/ms-Exch-Exchange-Server ObjectClass : {top, server, msExchExchangeServer} WhenChanged : 24.07.2018 13:35:43 WhenCreated : 29.07.2013 19:15:04 WhenChangedUTC : 24.07.2018 11:35:43 WhenCreatedUTC : 29.07.2013 17:15:04 OrganizationId : OriginatingServer : ad-srv.domain.local [PS] C:\Windows\system32>get-webservicesvirtualdirectory | fl RunspaceId : e9bb87e4-59a9-4145-8e95-41764b93c5e1 CertificateAuthentication : InternalNLBBypassUrl : https://exchange-srv.domain.local/ews/exchange.asmx GzipLevel : High MRSProxyEnabled : False MRSProxyMaxConnections : 100 Name : EWS (Default Web Site) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} LiveIdSpNegoAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True MetabasePath : IIS://exchange-srv.domain.local/W3SVC/1/ROOT/EWS Path : D:\Exchange2010\ClientAccess\exchweb\EWS ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} Server : exchange-srv InternalUrl : https://mobil.kundendomain.de/ews/exchange.asmx ExternalUrl : https://mobil.kundendomain.de/ews/exchange.asmx AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) DistinguishedName : CN=EWS (Default Web Site),CN=HTTP,CN=Protocols,CN=exchange-srv,CN=Servers,CN=Exchan ge Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=domain,CN=Mi crosoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local Identity : exchange-srv\EWS (Default Web Site) Guid : b3152da4-3c93-4f12-b2c1-f53b9a9cbe2a ObjectCategory : domain.local/Configuration/Schema/ms-Exch-Web-Services-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchWebServicesVirtualDirectory} WhenChanged : 24.07.2018 14:17:20 WhenCreated : 29.07.2013 19:22:29 WhenChangedUTC : 24.07.2018 12:17:20 WhenCreatedUTC : 29.07.2013 17:22:29 OrganizationId : OriginatingServer : ad-srv.domain.local IsValid : True [PS] C:\Windows\system32>get-oabvirtualdirectory | fl RunspaceId : e9bb87e4-59a9-4145-8e95-41764b93c5e1 Name : OAB (Default Web Site) PollInterval : 480 OfflineAddressBooks : {\Standard-Offlineadressbuch} RequireSSL : True BasicAuthentication : False WindowsAuthentication : True MetabasePath : IIS://exchange-srv.domain.local/W3SVC/1/ROOT/OAB Path : D:\Exchange2010\ClientAccess\OAB ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} Server : exchange-srv InternalUrl : https://mobil.kundendomain.de/oab InternalAuthenticationMethods : {WindowsIntegrated} ExternalUrl : https://mobil.kundendomain.de/oab ExternalAuthenticationMethods : {WindowsIntegrated} AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) DistinguishedName : CN=OAB (Default Web Site),CN=HTTP,CN=Protocols,CN=exchange-srv,CN=Servers,CN=Exchan ge Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=domain,CN=Mi crosoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local Identity : exchange-srv\OAB (Default Web Site) Guid : d274e93f-5c31-49f7-a274-fe5405e81513 ObjectCategory : domain.local/Configuration/Schema/ms-Exch-OAB-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchOABVirtualDirectory} WhenChanged : 24.07.2018 09:09:59 WhenCreated : 29.07.2013 19:22:06 WhenChangedUTC : 24.07.2018 07:09:59 WhenCreatedUTC : 29.07.2013 17:22:06 OrganizationId : OriginatingServer : ad-srv.domain.local IsValid : True [PS] C:\Windows\system32>get-owavirtualdirectory | fl RunspaceId : e9bb87e4-59a9-4145-8e95-41764b93c5e1 DirectFileAccessOnPublicComputersEnabled : True DirectFileAccessOnPrivateComputersEnabled : True WebReadyDocumentViewingOnPublicComputersEnabled : True WebReadyDocumentViewingOnPrivateComputersEnabled : True ForceWebReadyDocumentViewingFirstOnPublicComputers : False ForceWebReadyDocumentViewingFirstOnPrivateComputers : False RemoteDocumentsActionForUnknownServers : Block ActionForUnknownFileAndMIMETypes : ForceSave Url : {} LogonFormat : FullDomain ClientAuthCleanupLevel : High FilterWebBeaconsAndHtmlForms : UserFilterChoice NotificationInterval : 120 DefaultTheme : UserContextTimeout : 60 ExchwebProxyDestination : VirtualDirectoryType : OwaVersion : Exchange2010 ServerName : exchange-srv InstantMessagingCertificateThumbprint : InstantMessagingServerName : RedirectToOptimalOWAServer : True DefaultClientLanguage : 0 LogonAndErrorLanguage : 0 UseGB18030 : False UseISO885915 : False OutboundCharset : AutoDetect GlobalAddressListEnabled : True OrganizationEnabled : True ExplicitLogonEnabled : True OWALightEnabled : True DelegateAccessEnabled : True IRMEnabled : True CalendarEnabled : True ContactsEnabled : True TasksEnabled : True JournalEnabled : True NotesEnabled : True RemindersAndNotificationsEnabled : True PremiumClientEnabled : True SpellCheckerEnabled : True SearchFoldersEnabled : True SignaturesEnabled : True ThemeSelectionEnabled : True JunkEmailEnabled : True UMIntegrationEnabled : True WSSAccessOnPublicComputersEnabled : True WSSAccessOnPrivateComputersEnabled : True ChangePasswordEnabled : True UNCAccessOnPublicComputersEnabled : True UNCAccessOnPrivateComputersEnabled : True ActiveSyncIntegrationEnabled : True AllAddressListsEnabled : True RulesEnabled : True PublicFoldersEnabled : True SMimeEnabled : True RecoverDeletedItemsEnabled : True InstantMessagingEnabled : True TextMessagingEnabled : True ForceSaveAttachmentFilteringEnabled : False SilverlightEnabled : True CalendarPublishingEnabled : True OWAMiniEnabled : True InstantMessagingType : None Exchange2003Url : FailbackUrl : LegacyRedirectType : Silent CrossSiteRedirectType : Manual Name : owa (Default Web Site) InternalAuthenticationMethods : {Basic, Fba, Ntlm, WindowsIntegrated} MetabasePath : IIS://exchange-srv.domain.local/W3SVC/1/ROOT/owa BasicAuthentication : True WindowsAuthentication : True DigestAuthentication : False FormsAuthentication : True LiveIdAuthentication : False DefaultDomain : GzipLevel : High WebSite : Default Web Site DisplayName : owa Path : D:\Exchange2010\ClientAccess\owa ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} Server : exchange-srv InternalUrl : https://mobil.kundendomain.de/owa ExternalUrl : https://mobil.kundendomain.de/owa ExternalAuthenticationMethods : {Fba} AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) DistinguishedName : CN=owa (Default Web Site),CN=HTTP,CN=Protocols,CN=exchange-srv, CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN= Administrative Groups,CN=domain,CN=Microsoft Exchange,CN=Servi ces,CN=Configuration,DC=domain,DC=local Identity : exchange-srv\owa (Default Web Site) Guid : d6cb8401-3c4c-4cee-b3ad-b4f24f1d5431 ObjectCategory : domain.local/Configuration/Schema/ms-Exch-OWA-Virtual-Director y ObjectClass : {top, msExchVirtualDirectory, msExchOWAVirtualDirectory} WhenChanged : 24.07.2018 09:10:00 WhenCreated : 29.07.2013 19:22:02 WhenChangedUTC : 24.07.2018 07:10:00 WhenCreatedUTC : 29.07.2013 17:22:02 OrganizationId : OriginatingServer : ad-srv.domain.local IsValid : True [PS] C:\Windows\system32>get-ecpvirtualdirectory | fl RunspaceId : e9bb87e4-59a9-4145-8e95-41764b93c5e1 Name : ecp (Default Web Site) InternalAuthenticationMethods : {Basic, Fba, Ntlm, WindowsIntegrated} MetabasePath : IIS://exchange-srv.domain.local/W3SVC/1/ROOT/ecp BasicAuthentication : True WindowsAuthentication : True DigestAuthentication : False FormsAuthentication : True LiveIdAuthentication : False DefaultDomain : GzipLevel : High WebSite : Default Web Site DisplayName : ecp Path : D:\Exchange2010\ClientAccess\ecp ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} Server : exchange-srv InternalUrl : https://mobil.kundendomain.de/ecp ExternalUrl : https://mobil.kundendomain.de/ecp ExternalAuthenticationMethods : {Fba} AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) DistinguishedName : CN=ecp (Default Web Site),CN=HTTP,CN=Protocols,CN=exchange-srv,CN=Servers,CN=Exchan ge Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=domain,CN=Mi crosoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local Identity : exchange-srv\ecp (Default Web Site) Guid : 70679a5d-a17d-465d-af09-ec2a8c7a5cbf ObjectCategory : domain.local/Configuration/Schema/ms-Exch-ECP-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchECPVirtualDirectory} WhenChanged : 24.07.2018 09:10:03 WhenCreated : 29.07.2013 19:22:08 WhenChangedUTC : 24.07.2018 07:10:03 WhenCreatedUTC : 29.07.2013 17:22:08 OrganizationId : OriginatingServer : ad-srv.domain.local IsValid : True [PS] C:\Windows\system32>get-ActiveSyncVirtualDirectory | fl RunspaceId : e9bb87e4-59a9-4145-8e95-41764b93c5e1 MobileClientFlags : BadItemReportingEnabled, SendWatsonReport MobileClientCertificateProvisioningEnabled : False BadItemReportingEnabled : True SendWatsonReport : True MobileClientCertificateAuthorityURL : MobileClientCertTemplateName : ActiveSyncServer : https://mobil.kundendomain.de/Microsoft-Server-ActiveSync RemoteDocumentsActionForUnknownServers : Allow RemoteDocumentsAllowedServers : {} RemoteDocumentsBlockedServers : {} RemoteDocumentsInternalDomainSuffixList : {} MetabasePath : IIS://exchange-srv.domain.local/W3SVC/1/ROOT/Microsoft-Server-ActiveS ync BasicAuthEnabled : True WindowsAuthEnabled : False CompressionEnabled : True ClientCertAuth : Ignore WebsiteName : Default Web Site WebSiteSSLEnabled : True VirtualDirectoryName : Microsoft-Server-ActiveSync Path : ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} Server : exchange-srv InternalUrl : https://mobil.kundendomain.de/Microsoft-Server-ActiveSync InternalAuthenticationMethods : {} ExternalUrl : https://mobil.kundendomain.de/Microsoft-Server-ActiveSync ExternalAuthenticationMethods : {} AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) Name : Microsoft-Server-ActiveSync (Default Web Site) DistinguishedName : CN=Microsoft-Server-ActiveSync (Default Web Site),CN=HTTP,CN=Protocols,CN= exchange-srv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDL T),CN=Administrative Groups,CN=domain,CN=Microsoft Exchange,CN=Services ,CN=Configuration,DC=domain,DC=local Identity : exchange-srv\Microsoft-Server-ActiveSync (Default Web Site) Guid : d8d3d907-c4f5-4fbd-9ba2-7db405530c2f ObjectCategory : domain.local/Configuration/Schema/ms-Exch-Mobile-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchMobileVirtualDirectory} WhenChanged : 24.07.2018 09:09:56 WhenCreated : 29.07.2013 19:22:26 WhenChangedUTC : 24.07.2018 07:09:56 WhenCreatedUTC : 29.07.2013 17:22:26 OrganizationId : OriginatingServer : ad-srv.domain.local IsValid : True Was habe ich übersehen? Ich habe einen anderen Exchange 2010 Server eines anderen Kunden, der genauso konfiguriert ist. Nur hier meckert Outlook nicht... Ich bin für jede Möglichkeit offen und für jeden Rat dankbar! Viele Grüße aus dem viel zu warmen Kiel

Danke für den Tipp, Norbert! ich musste allerdings die W32Time.admx und die adml von einem anderen Server 2016er in den central store kopieren.

Hi liebes Forum, ich habe hier ein Problem und komme nicht weiter: Ich habe auf einem DC (Server 2008R2) eine GPO, die den NTP Server ausrollen soll. Nur scheint hier der "Verzeichnisbaum" defekt zu sein - siehe Anhänge. Der Eintrag "Windows-Zeitdienst" ist in einem Ordner "Windows-NTP-Server aktivieren", welcher eigentlich ein Eintrag und kein Ordner sein soll... Ich habe mittlerweile einen neuen DC in dieser Domäne (Server 2016) - das selbe Bild. Kann man das irgendwie reparieren?? Viele Grüße Andy

So, sorry für die späte Antwort. Die Lösung des Problems: Ja, es war die Firewall ;-) Die Juniper Firewall kommt hier mit ALGs (Application Layer Gateways) um die Ecke, die per default aktiv sind. Es handelte sich hierbei um das ALG MSRPC. Hat nun ja auch jahrelang funktioniert. Ob jetzt MS was geändert hat, oder die Juniper auf einmal meint einige Pakete wegzuschmeißen, weil die nun nicht mehr passen... keine Ahnung. Wir haben nun das ALG deaktiviert (set security alg msrpc disable) - und schlagartig funzt das wieder. Danke für die Unterstützung!

Sobald ich versuche die Vertrauensstellung zu erstellen, klettert die CPU Last auf 50% und die MMC reagiert nicht mehr (siehe Screenshot)

Ping, NSLOOKUP, SMB alles funktioniert. Ich sehe auf dem Router zwischen den beiden Netzen ja auch, dass die Pakete korrekt geroutet werden. Ich habe jetzt Server_C in das Netz gebracht, von dem ich - wie oben beschrieben - die Vertrauensstellung jederzeit löschen und neu aufbauen konnte, um das Routing auszuschließen. Server_A befindet sich im Netz 192.168.1.0/24 Server_C befindet sich im Netz 192.168.2.0/24 Es funktioniert einfach nicht. Der Server, der ohne Weiteres den Trust löschen und neu aufbauen und anschließend auch überprüfen kann (auch ein Server 2008R2) befindet sich ebenfalls in dem Netz 192.168.2.0/24 Zwischen den Netzen gibt es den einen Router, der über EINE Regel für jede Richtung Netzwerkverkehr zulässt - wie oben beschrieben Port "Any" - Das ist doch nicht normal! Was übersehe ich denn hier?!?

Hi Liebes Forum! Ich bin hier mittlerweile seit ein paar Tagen am Verzweifeln! Vielleicht sehe ich einfach den Wald vor lauter Bäumen nicht mehr: Folgende Voraussetzungen sind gegeben: Subnetz_A Subnetz_B Subnetz_C Subnetz_D Server_A_2008R2 Server_B_2008R2 Server_C_2012R2 Server_D_2008R2 Server_A_2008R2 hat Vertrauensstellungen in viele externe Domänen (zurzeit 27), die alle in anderen Subnetzen unterwegs sind (ein Router dazwischen). Jetzt gibt es einen neuen Server_C_2012R2 (Subnetz_C), der ebenfalls eine Vertrauensstellung in die Domäne des Server_A_2008R2 (Subnetz_A) herstellen soll. Bedingte Weiterleitung im DNS für die andere Domäne ist jeweils eingerichtet und lässt sich via NSLOOKUP auch auflösen (in beide Richtungen). Die Firewall ist auf beiden Systemen deaktiviert und der Router zwischen den beiden Systemen soll jeden Verkehr auf allen Ports zulassen (any). Wenn ich jetzt versuche eine Bidirektionale Vertrauensstellung (exakt wie die anderen Zig Vertrauensstellungen auch) einzurichten, schlägt diese fehl, wenn versucht wird von dem einen Server auch gleich die Vertrauensstellung auf den anderen Server einzurichten (im Assistenten „Für diese Domäne und die angegebene Domäne“). Fehler beim Vorgang: Der Remoteprozeduraufruf (RPC) wurde abgebrochen. Wenn ich die Vertrauensstellung erst auf dem einen und dann auf dem anderen Server manuell einrichte, kann diese anschließend nicht überprüft werden und schlägt nach ca. 5 Minuten mit der Meldung fehl: Beim erneuten Festlegen des sicheren Kanals auf dem Active Directory-Domänencontroller „server.testdomain.local“ der Domäne „testdomain.local“ mit Domäne „testdomain-2.local“ ist folgender Fehler aufgetreten: Der Remoteprozeduraufruf (RPC) wurde abgebrochen. Ich kann allerdings so Benutzer der fremden Domäne auf einen Ordner berechtigen (dies funktioniert auf beiden Servern). Wenn ich dann anschließend die Eigenschaften -> Sicherheit dieses Ordners öffne, werden nur die SIDs angezeigt (nach eine Weile löst Windows die Benutzer der eigenen Domäne auf, der Benutzer aus der fremden Domäne bleibt allerdings als SID…) Wenn die Server sich im selben Subnetz befinden, geht alles wie es soll!! Nur, wenn die Server in unterschiedlichen Subnetzen unterwegs sind, klappt es nicht. Kurios: Wenn ich eine BESTEHENDE Vertrauensstellung auf beiden Seiten lösche (Server befinden sich ebenfalls in unterschiedlichen Subnetzen), kann diese wie gewohnt eingerichtet werden - ohne Fehlermeldung Ich habe jetzt auch noch einen neuen Server_B_2008R2 (in Subnetz_B) und einen neuen Server_D_2008R2 (in Subnetz_D) erstellt - AD Rolle drauf, DNS und Domäne eingerichtet, Weiterleitung eingerichtet und getestet, Firewall deaktiviert, Vertrauensstellung versucht einzurichten - das selbe Ergebnis! Auf der Firewall sehe ich alle Pakete von Server_B_2008R2 nach Server_D_2008R2 und umgekehrt den Router verlassen (packet passed, Permitted by policy). Gab es ein Windows Update, welches nun Vertrauensstellungen in Domänen anderer Subnetze nicht mehr zulässt (Registry Setting)?! Ich beiß mir an dieser Sache zusammen mit einem Kollegen echt die Zähne aus… Bin für jeden Hinweis dankbar! Gruß Andy

@Jan: Du hast vermutlich Recht! Ich werde das mit dem dummy Postfach so machen! Danke euch allen für die schnelle und kompetente Hilfe! :thumb1:

Hi Jan, ja, ist eine Möglichkeit, die wir auch schon in Betracht gezogen hatten. Der Kunde quengelt aber wegen der Exchange CALs... Wenn's die einzige Möglichkeit ist, werden wir das dann doch so machen müssen. Ich bin aber immer noch offen für Alternativen :D Gruß Andy

Hi, @Jan: Die drei Benutzer haben kein eigenes E-Mail Postfach, deshalb kann ich sie nicht direkt berechtigen oder in eine Verteilergruppe packen. @ Norbert: Auf diesen und andere Kalender im öffentlichen Ordner greifen sehr viele andere Benutzer (mit eigenem Postfach) zu und das soll nach Möglichkeit auch bestehen bleiben. So wie es aussieht meldet sich Outlook eben nicht - wie angezeigt (Öffentliche Ordner - test@domain.com) mit dem Benutzer test@domain.com am Exchange an, sondern mit dem jeweiligen Benutzer (Müller, Meier oder Schulze). Das sieht mir so, als wäre das ein Bug im Outlook. Ich kann leider nicht feststellen, ob dieses Problem auch bei älteren Outlook Versionen auftritt. Noch 'ne Idee? Gruß Andy

Hi, ich habe hier ein Problem mit gemeinsam genutzten Postfächern und öffentlichen Ordnern. Der Aufbau ist wie folgt: Die Benutzer Müller, Meier und Schulze haben nur ein AD Konto und Vollzugriff (mit senden als) auf das E-Mail Konto test@domain.com. Das Versenden und Empfangen von E-Mails funktioniert bei den dreien tadellos. Jetzt gibt es einen öffentlichen Kalender "Gemeinsamer_Kalender" und auf eben diesen hat der Benutzer test@domain auch Zugriff. Wenn ich mich mit dem Benutzer test@domain.com über OWA anmelde sehe ich auch diesen Kalender. Die Benutzer Müller, Meier und Schulze sehen unter "Öffentliche Ordner - test@domain.com", sehen aber nicht den öffentlichen Kalender "Gemeinsamer_Kalender". Ich habe auch schon eine E-Mail aktivierte Sicherheitsgruppe angelegt, die Benutzer Müller, Meier und Schulze als Mitglieder ernannt und diese Gruppe dann ebenfalls in dem öffentlichen Ordner berechtigt - leider ohne Erfolg... Gibt es für dieses Problem eine Lösung? Server: Exchange 2010 E-Mail Client: Outlook 2013 Danke schon einmal für eure Mühen! Gruß Andy

Moin, super Idee! Die einfachsten Dinge sind doch immer noch die Besten! :jau: Dankeschön!

Hi, ich sehe den Wald vor lauter Bäumen nicht... Ich habe hier zwei Domänen (eine neue und eine alte, die bald "sterben"soll) und habe keinen Trust eingerichtet (bei der desolaten Domäne auch kaum noch möglich.). Nun soll für die Migration jedem Benutzer der alte Datenbestand des alten Servers den neuen Benutzern des neuen Servers zur Verfügung gestellt werden. Da es sich hier um eine in viele Ebenen verzweigte Dateistruktur handelt mit fürchterlich eingerichteten Benutzer-Zugriffsrechten, soll - und kann - dieser Datenbestand nicht 1:1 in die neue Domäne kopiert werden. Nun ist meine Frage: Ist es möglich über EIN Anmeldescript jedem Benutzer dieses Laufwerk mit seinen alten Zugangsdaten zur Verfügung stellen? Ich möchte es vermeiden, jedem Benutzer (ca. 250) ein eigenes Anmeldescript mit "net use X:IP-ADRESSE /u:DOMAIN\USERNAME PASSWORD" basteln zu müssen. Es soll so aussehen, dass jeder Benutzer EINMAL seine alten Anmeldedaten eingibt und bei der nächsten Anmeldung nicht mehr... Folgende Möglichkeiten habe ich schon ausprobiert: GPO: Benutzer -> Windows-Einstellungen -> Laufwerkzuordnungen Wenn ich hier die Adresse des Servers der anderen Domäne eintrage, dauert die Anmeldung ewig (Drive Mapping) und im Ereignisprotokoll des Servers ist zu sehen, dass ihm die Anmeldeinformationen fehlen. Hab' ja auch keine Eingetragen - soll ja der User selbst machen ;) Logon Script (cmd): echo Bitte hier den alten Benutzernamen eintragen: set /p username= echo Bitte hier das alte Passwort eintragen: set /p password= net use t: /delete net use t: "\\192.168.110.32\ohbhfs" /User:ohbh\%username% %password% /persistent:no Das ist soweit schonmal nicht schlecht - Hier muss der User aber jedes mal die Daten eintragen... Will ich auch nicht. Hat jemand noch 'ne Idee? Am liebsten wäre es mir, wenn der User ein Netzlaufwerk sieht, und bei Doppelklick darauf nach den alten Daten gefragt wird.

Hi, ich habe hier zwei HP Switches (Typ 2510G-48), die über Port 48 miteinander verbunden sind (backup). Schleifen sollen mit RSTP verhindert werden. Ein Switch ist die root-bridge, der andere eben nicht :) Ports 1-47 sind admin-edge-ports und haben ebenfalls die bpdu-protection. Nun zu meinem Problem: Ich stecke alle weiteren Switche und Rechner (keine rstp fähigen Geräte) in die root-bridge (alles separate VLANs) - soweit alles gut! Nun fange ich an den zweiten Switch zu bestücken. Ich stecke das Kabel in den Port -> dieser leuchtet kurz auf und ich verliere 2-3 Pings, dann schaltet dieser Switch den Port aus (ist das ein normales Verhalten?). Jetzt gibt es aber andere Geräte (CISCO Switch ohne RSTP), bei denen der zweite Switch den Port aktiv lässt - ich verliere hier auch 2-3 Pings, danach ist aber wieder alles gut! Hier noch ein Auszug der spanning-tree debug-counters: non-root-bridge: Counter Name Aggregated Value Collected From --------------------------------- ---------------- -------------- Invalid BPDUs 0 CIST Errant BPDUs 0 CIST MST Config Error BPDUs 0 CIST Looped-back BPDUs 0 CIST Starved BPDUs/MSTI MSGs 0 CIST/MSTIs Exceeded Max Age BPDUs 0 CIST Exceeded Max Hops BPDUs/MSTI MSGs 0 CIST/MSTIs Topology Changes Detected 1 CIST/MSTIs Topology Changes Tx 2 CIST/MSTIs Topology Changes Rx 0 CIST/MSTIs Topology Change ACKs Tx 0 CIST Topology Change ACKs Rx 0 CIST TCN BPDUs Tx 0 CIST TCN BPDUs Rx 0 CIST CFG BPDUs Tx 0 CIST CFG BPDUs Rx 0 CIST RST BPDUs Tx 3612 CIST RST BPDUs Rx 1169 CIST MST BPDUs/MSTI MSGs Tx 0 CIST/MSTIs MST BPDUs/MSTI MSGs Rx 0 CIST/MSTIs root-bridge: Counter Name Aggregated Value Collected From --------------------------------- ---------------- -------------- Invalid BPDUs 0 CIST Errant BPDUs 0 CIST MST Config Error BPDUs 0 CIST Looped-back BPDUs 0 CIST Starved BPDUs/MSTI MSGs 0 CIST/MSTIs Exceeded Max Age BPDUs 0 CIST Exceeded Max Hops BPDUs/MSTI MSGs 0 CIST/MSTIs Topology Changes Detected 45 CIST/MSTIs Topology Changes Tx 700 CIST/MSTIs Topology Changes Rx 25 CIST/MSTIs Topology Change ACKs Tx 1 CIST Topology Change ACKs Rx 0 CIST TCN BPDUs Tx 0 CIST TCN BPDUs Rx 1 CIST CFG BPDUs Tx 6313 CIST CFG BPDUs Rx 3783 CIST RST BPDUs Tx 731075 CIST RST BPDUs Rx 288525 CIST MST BPDUs/MSTI MSGs Tx 0 CIST/MSTIs MST BPDUs/MSTI MSGs Rx 0 CIST/MSTIs Ich habe noch nicht viel Erfahrung mit RSTP, gerade mit dem Troubleshooting :shock:

Ich habe nun diesen TC umbenannt. Jetzt hat dieses Gerät eine Temporäre Lizenz erhalten, obwohl ich noch 133 Lizenzen frei habe. Nun kann sich auch der Benutzer über diesen TC anmelden. Ist dieses Verhalten normal, dass eine zuerst temporäre Lizenz ausgestellt wird?

Ja, geht das denn auch bei einem 2003er TS?

Hi, mein Terminalserver bringt mich zur Weißglut :mad: Ich habe hier einen ThinClient von HP - Name: TC-HP -, der sich an einem Terminalserver anmelden soll. Das hat erst auch funktioniert (temporäre Lizenz wurde ausgestellt). Nun habe ich weitere Device CALs installiert (Lizenzmodus ist auch per Device). Alle anderen Rechner/ThinClients haben nun auch eine "richtige" Lizenz und können arbeiten. Nur dieser eine TC wird abgewiesen mit der Ereigniskennung 1011 (Die Verbindung mit dem Terminalserverclient TC-HP wurde getrennt, da dessen temporäre Lizenz abgelaufen ist. Der Lizenzserver MeinLizenzserver wurde kontaktiert um eine "Windows Server 2003 - Terminalserver-CAL-Token (pro Gerät)" Lizenz für diesen Client zu erhalten.). Schaue ich nun in der Terminalserverlizensierung nach, hat dieser TC eine "Windows Server 2003 - Terminal Server Per Device CAL Token" Lizenz ausgestellt bekommen (Ausgestellt am 02.05.2012 - gültig bis 15.07.2012). Die Verbindung wird aber dennoch abgelehnt mit eben diesem Ereignis 1011. Ich habe auch nicht die Möglichkeit auf dem TC in der Registrierung etwaige Einträge zu löschen (HKLM/CurrentControlSet/Services/etc....). Ich habe jetzt noch nicht versucht den TC umzubenennen (dann geht mir ja eine Lizenz flöten, oder?). Hat jemand eine Idee was man da sonst machen kann?

PROBLEM GELÖST!! Es war zum Einen der Eintrag in der Registry "EnableOnLoad" http://support.microsoft.com/kb/2570623/en-us und zum Anderen dieser Beitrag: http://www.mcseboard.de/windows-server-forum-78/excel-dateien-bearbeiten-nur-smb-sehr-langsam-2-178393.html#post1099727 Vielen Dank an alle, die mitgewirkt haben!! Großes Lob!! :jau: :thumb1:

Danke für die Links zu den Tools. Bin gerade am Testen. Das, was bei technet besprochen wird, habe ich auch bereits gemacht: