Andreas83

Guten Morgen Nobby,

da gebe ich dir recht, an Veeam wenden damit keine Checkpoints mehr hängen bleiben, doch mein aktuelles Problem wird Veeam sagen dass die damit nichts zu tun haben. Habe etwas recherchiert und die zwei oben genannten Möglichkeiten gefunden, eine über Hyper-V Manager Datenträger bearbeiten und dann manuell in Einstellungen Platte auswählen und die andere per Powershell.

PoweShell ging einwandfrei, manuelle weg aber nicht. Da wird mir Veeam nicht helfen können.

also bleibt nur Export, VM löschen und Import 

Hallo zusammen, 

durch die Veeam Sicherung (9.5) kam es bei 2 VMs auf einem Host 2016 zu mehreren Prüfpunkten die über die Hyper-V Console nicht direkt gelöscht werden können. 

Beider Variante über Datenträger bearbeiten um die avhdx mit der übergeordneten zusammenzuführen, wurde dies zwar gemacht, aber die Historie in Prüfpunkte bleibt erhalten.

In den Einstellungen habe ich die vhdx auch manuell als Platte gewählt. 

Jemand eine Idee wie ich die Historie "sauber" bekomme?

Bei der zweiten VM habe ich es per Powershell gemacht, hier wird dann auch die Historie geleert und die Einstellung in der VM auf die .vhdx geändert. 

Export und Import wäre der nächste Versuch. 

Andere Frage, kann mir gerade jemand sagen, wenn ich ein Veeam VM Restore durchführe, werden dann die Prüfpunkte auch wiederhergestellt oder sind diese dann weg?

Danke und ein schönes Wochenende

Hallo, 

habe eine Frage zur VM Replizierung unter 2016 die ich aktuell nicht testen kann.

Sagen wir es gibt 2 Hosts die je 4 VMs hosten mit denen die physikalische Kiste ausgelastet ist. 

Es soll aus Kostengründen keine Hochverfügbarkeit angeschafft werden, fällt ein Host aus, möchte man aber Zeitnah weiterarbeiten.

Hätte man einen weiteren Host, CPU und RAM identisch der 2 Hosts aber mit genügend HDDs.

Kann ich die 8 VMs (je Host 4 Stück) auf den dritten Host replizieren, trotz mangelnder vCPUs? Im Ernstfall sollen lediglich 4 VMs gestartet werden (wo die CPUs und RAM dann ausreichend wären).

Oder streikt hier die Replizierung weil Hyper-V meckert dass nicht genügend Ressourcen verfügbar sind. 

An sich kann ich doch mehrere ausgeschaltete VMs anlegen, erst wenn die Anzahl der gestarteten VMs die Ressourcen übersteigt, wird gemeckert, oder?

keine eine Idee?

Hallo zusammen,

wenn ich in Windows 10 die benutzerdefinierte Skalierung auf 110 einstelle, führt die zu einer höheren Excel Zeile. Standard sind 15,00 und mit 110er Skalierung sind es dann 15,75

was wiederum dazu führt dass die ganzen Vorlagen nicht mehr auf die gewünschte Seitenzahl passt.

Habt ihr mir hier eine Idee?

Windows Firewall hat tatsächlich den PING blockiert. 

Dass durch die oben genannte Firewall-Richtlinie Zugriff auf die R1200 Weboberfläche blockiert wurde muss ich aber wirklich noch im Handbuch nachschauen.

Danke allen beteiligten.

Guten Morgen zusammen,

erstmal Sorry für das aufmachen des uralten Threads und danke Dr.Melzer dass du bereits einen neuen erstellt hast. 

@Sanches

ja, wenn ich in den Richtlinien sage, dass Quelle en1-1  <-> Ziel en1-2 Dienst any erlaube, dann erscheint: 

The required components could not be loaded.

und ich habe danach keinen Zugriff mehr auf die Weboberfläche und auch Ping ist nicht mehr möglich.

@lefg

danke für die hilfreiche Antwort, du hast Recht, ich hätte das 575 seitige Handbuch lesen sollen. 

Hallo, 

ich habe ein ähnliches Problem, auch wenn das Thema hier schon sehr alt ist, mal ein Versuch. 

Habe am R1200 an 

en1-1 192.168.1.1 einen Windows Client mit der 192.168.1.50 zum Test default Gateway auf 192.168.1.1 gesetzt

en1-2 192.168.2.1 einen Windows Client mit der 192.168.2.50 zum Test default Gateway auf 192.168.2.1 gesetzt

Jeder Client kann die eigene und andere Gateway IP pingen, nicht aber den anderen Client.

Kenne mich mit den Bintec Konfigurationen nicht aus. 

Kann mir jemand sagen, was ich zu konfigurieren habe dass 192.168.1.50 mit 192.168.2.50 kommunizieren kann?

Vielen Dank.

keiner mehr eine Idee?

ja, öffentlichen SAN mit autodiscover.domain.de und remote.domain.de

gebootet ja...

wenn ich das Profil lösche udn neu anlege geht es ja, aber das will ich nicht bei allen clients machen.

Guten Morgen, 

habe mich schlecht ausgedrückt, es gibt keinen physikalisch alten/neuen sondern nur Namentlich da wir von einem internen privaten Zertifikat nun in Verbindung mit Split DNS auf ein externes öffentliches Zertifikat gewechselt haben. Daher im Exchange alles angepasst intern = externe URLs usw. 

Exchange 2013 aktuell gepatcht und Client haben wir das Problem bei Outlook 2010 sowie 2013 auf aktuell gepatchten Windows 7

Was meinst du mit den Schaltflächen als JA / Nein / weiss nicht? 

Starte mmc, füge Snap-In Zertifikate hinzu... und dann? 

Hallo zusammen, 

den ganzen morgen bin ich auf der Suche nach einer Lösung damit diese Meldung verschwindet. 

Am Client das Exchange Profil löschen und neu anlegen bringt den gewünschten Erfolg, daher gehe ich davon aus, 

dass Server seitig alles korrekt eingerichtet ist. 

Irgendwo muss doch diese doofe Information zum "alten Proxyserver" gespeichert sein. Registry Eintrag oder lokale Datei...

aber ich finde nichts. 

Hat noch jemand von euch eine Idee? 

Ich will nicht alle Outlook Profile manuell neu einrichten. 

Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. Der Name des Sicherheitszertifikats

ist ungültig oder entspricht nicht dem Namen der Zielwebseite 'mail.[unsere-web-domain].de'.
Von Outlook kann keine Verbindung mit dem Proxyserver hergestellt werden (Fehlercode: 10).

Danke.

Grüße Andreas

Hallo Peter, 

stand vor einem ähnlichen Problem. Wir haben die Subdomain geändert und daher kam immer beim Start von Outlook die Zertifikat Meldung und Outlook hat sich nicht verbunden.

Nachdem im IIS im Backend das gleiche Zertifikat manuell verwendet wurde hat Outlook verbunden aber Meldung kam weiterhin. 

Nach:

Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:remote.kundendomain.com
Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:remote.kundendomain.com
Set-OutlookProvider -Identity WEB -CertPrincipalName msstd:remote.kundendomain.com

werden die Einstellungen wieder korrekt eingetragen, aber erst nachdem ich RPC over HTTPS im Profil deaktiviert habe,

dann wird nach einem Outlook Neustart diese Option wieder gesetzt und die korrekte Domain eingetragen.

Aber leider muss ich manuell tätig werden. Habe ich zu wenig Geduld oder wie kann ich vom Server aus diese Einstellungsänderung  erzwingen?

Hallo nochmal,

abschließend noch eine Info, auch wenn es nur ein Workaround ist bis ich entweder einen Anschluss mit mehreren IP habe oder einfach einen zweiten schnellen V-DSL.

Auch wenn es für den ein oder anderen nicht die sauberste Lösung ist, mir hilft Sie temporär. 

a) Ich habe nun 443 ohne Reverse Proxy für DirectAccess an den DirectAccess Server weitergeleitet. 

b) DirectAccess funktioniert nun per LTE und V-DSL Anschlüssen (Probleme noch mit UnityMedia aber das ist ein anderes Thema)

c) für Smartphone habe ich am Gateway 9443 an intern 443 weitergeleitet, somit profitiert diese Verbindung nun auch vom V-DSL

d) Outlook komuniziert über DirectAccess mit Exchange, somit brauche ich hier gar kein 443 mehr weiterleiten. 

Nun heißt es nur noch dieses verdammte Problem lösen dass es an bzw. mit vielen UnityMedia Anschlüssen Probleme gibt, trotz dass mein eigener tarif einer ist wo ich eine richtige IPv4 Adresse erhalte, nix DS-Lite oder sonst was.

Aber dazu gibt es schon ein Thema von mir, entweder rolle ich das nochmal auf oder erstelle ein neues.

Danke nochmal für eure Vorschläge 

wäre es denkbar in den GPO die URL für den Client auf z.B. 8443 anzupassen und dann anstelle des Reverse Proxy eine Portweiterleitung an den internen DirectAccess Server auf Port 443 zu konfigurieren?

das klingt alles andere als gut. Dann kann ich nur hoffen ich bekomme bald einen zweiten VDSL :-(

Wenn noch jemand eine Idee hat, bitte her damit. 

Genau, habe ich oben beschrieben, OWA zeigt das Let's Encrypt Zertifikat.

Muss ich direct Access was beachten? Gerade wegen Zertifikat zwischen Firewall und DirectAccess Server?

der Reverse Proxy wird im HTTPS Modus betrieben somit wir die Verbindung vom Proxy terminiert und zum internen Server eine zweite HTTPS Verbindung aufgebaut. So die Aussage des Firewall Supports

Guten Morgen, 

ich hatte bis gestern ein funktionierendes DirectAccess auf einem 2012 R2 mit selbst signiertem Zertifikat was bei der Einrichtung des DirectAccess automatisch mit der externen Domain erstellt wurde. Diese Domain verweist auf meine WAN IP und 443 wurde an den DirectAccess Server weitergeleitet.

Nun haben wir aber mehrere Dienste welche 443 benötigen. Somit habe ich in unserer GateProtect (Rhode & Schwarz) GPO-150 den Reverse Proxy aktiviert, bei Let´s Encrypt ein 90 Tage Zertifikat mit mehreren Subdomains erstellt und im Reverse Proxy eingebunden. 

Dienst wie Outlook Anywhere oder OWA funktionieren einwandfrei. Im Browser sehe ich das Let´s Encrypt Zertifikat. 

Beim Exchange habe ich auch ein selbst signiertes Zertifikat was ich nach Einbindung des Reverse Proxy aber nicht bzw. noch nicht angefasst habe. Daher habe ich auch beim DirectAccess noch keine Veränderungen vorgenommen.

Leider funktioniert DirectAccess nicht. 

Habt ihr mir hier einen Ansatz was ich noch tun muss, was ich evtl. übersehen habe? 

Vielen Dank für jeden Hinweis. 

Grüße Andreas

sieht nun gut aus, Meldung erscheint bisher nicht mehr. 

Vielen Dank euch!

hatte die Info aus dem Technet Forum. Script läuft durch und meckert, wie du es auch geschrieben hast, dass es kein AutodiscoverServiceExternalUri gibt.

An sich ja aber kein Fehler es so zu machen um die ps1 Datei auch an einem anderen Exchange nutzen zu können. Sollte so korrekt sein. Oder?

$urlpath = Read-Host "Bitte URL eingeben"

Get-ClientAccessServer –Identity * | Set-ClientAccessServer –AutodiscoverServiceInternalUri "$urlpath/autodiscover/autodiscover.xml"
Set-webservicesvirtualdirectory –Identity * –internalurl "$urlpath/ews/exchange.asmx"
Set-oabvirtualdirectory –Identity * –internalurl "$urlpath/oab"
Set-owavirtualdirectory –Identity * –internalurl "$urlpath/owa"
Set-ecpvirtualdirectory –Identity * –internalurl "$urlpath/ecp"
Set-ActiveSyncVirtualDirectory -Identity * -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"

Get-ClientAccessServer –Identity * | Set-webservicesvirtualdirectory –Identity * -ExternalUrl "$urlpath/ews/exchange.asmx"
Set-oabvirtualdirectory –Identity * –ExternalUrl "$urlpath/oab"
Set-owavirtualdirectory –Identity * –ExternalUrl "$urlpath/owa"
Set-ecpvirtualdirectory –Identity * –ExternalUrl "$urlpath/ecp"
Set-ActiveSyncVirtualDirectory -Identity * -ExternalUrl "$urlpath/Microsoft-Server-ActiveSync"

neues Profil hat nicht geholfen. In einem anderen Forum habe ich nochmal von den internen und externen URLs gelesen und entsprechend die Abfragen in der Shell gemacht. hier das Ergebnis. Denke da passt was noch nicht. 

[PS] C:\Windows\system32>get-AutodiscoverVirtualDirectory

Name                            Server     InternalUrl
----                            ------     -----------
Autodiscover (Default Web Site) OBR-SRV-EX

[PS] C:\Windows\system32>get-ClientAccessServer

Name
----
OBR-SRV-EX

[PS] C:\Windows\system32>get-webservicesvirtualdirectory

Name                   Server     InternalUrl
----                   ------     -----------
EWS (Default Web Site) OBR-SRV-EX https://obr-srv-ex.intern.local/EWS/Exchange.asmx

[PS] C:\Windows\system32>get-oabvirtualdirectory

Server     Name                   Internal Url                              External Url
------     ----                   ------------                              ------------
OBR-SRV-EX OAB (Default Web Site) https://mail.externdomain.de/OAB https://mail.externdomain.de/OAB

[PS] C:\Windows\system32>get-owavirtualdirectory

Name                   Server     OwaVersion
----                   ------     ----------
owa (Default Web Site) OBR-SRV-EX Exchange2010

[PS] C:\Windows\system32>get-ecpvirtualdirectory

Name                   Server
----                   ------
ecp (Default Web Site) OBR-SRV-EX

[PS] C:\Windows\system32>get-ActiveSyncVirtualDirectory

Name                                           Server     InternalUrl
----                                           ------     -----------
Microsoft-Server-ActiveSync (Default Web Site) OBR-SRV-EX https://mail.externdomain.de/Microsoft-Server-Act...

Soll ich wie im MS Technet Forum beschrieben alle so anpassen?

To set the URL's for all directories at once, run the following powershell commands (save it as a .ps1 extension and run it in EMS)

For internal URLs:

$urlpath = Read-Host "Type internal Client Access FQDN starting with http:// or https://"

Get-ClientAccessServer –Identity * | Set-ClientAccessServer –AutodiscoverServiceInternalUri "$urlpath/autodiscover/autodiscover.xml"
Set-webservicesvirtualdirectory –Identity * –internalurl "$urlpath/ews/exchange.asmx"
Set-oabvirtualdirectory –Identity * –internalurl "$urlpath/oab"
Set-owavirtualdirectory –Identity * –internalurl "$urlpath/owa"
Set-ecpvirtualdirectory –Identity * –internalurl "$urlpath/ecp"
Set-ActiveSyncVirtualDirectory -Identity * -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"

External URLs:

Get-ClientAccessServer –Identity * | Set-ClientAccessServer –AutodiscoverServiceExternalUri "$urlpath/autodiscover/autodiscover.xml"
Set-webservicesvirtualdirectory –Identity * -ExternalUrl "$urlpath/ews/exchange.asmx"
Set-oabvirtualdirectory –Identity * –ExternalUrl "$urlpath/oab"
Set-owavirtualdirectory –Identity * –ExternalUrl "$urlpath/owa"
Set-ecpvirtualdirectory –Identity * –ExternalUrl "$urlpath/ecp"
Set-ActiveSyncVirtualDirectory -Identity * -ExternalUrl "$urlpath/Microsoft-Server-ActiveSync"

Beide URLs sind vorhanden und intern funktioniert einwandfrei. https://mail.meinedomain.de/owa zeigt OWA ohne Zertifikatsfehler. 

Service Connection Point (SCP) habe ich auch geprüft, zeigt auch auf die mail.meinedomain.de

sorry, habe unter Serverkonfiguration, Clientzugriff die interne der externen URL für alle Reiter wie OWA usw. gleichgesetzt.

Mit Get-ClientAccessServer | fl Name, AutoDiscoverServiceInternalUri

erhalte ich die interne URL

https://obr-srv-ex.domain.local/Autodiscover/Autodiscover.xml

Konnte es mit 

Set-ClientAccessServer name -AutoDiscoverServiceInternalUri https://autodiscover.yourdomain.com/Autodiscover/Autodiscover.xml

ändern.

Server Neustart wurde zur Sicherheit durchgeführt aber die Meldung erscheint weiterhin. 

Noch eine Idee?

SP3 Update Rollup 15 ist ist installiert. 

Vielen Dank

ich habe die internen der externen URLs gleich gesetzt und bei Let´s Encrypt zwei Aliase hinterlegt, autodiscover.domain.de sowie mail.domain.de.

Intern SplitDNS konfiguriert. Aber irgendwo muss ich eine Einstellung am Exchange vergessen oder übersehen haben. 

Selbst wenn ich ein neues Exchange Profil anlege und als Server mail.domain.de verwende, kommt die Meldung nach dem Outlook start.

Irgendwoher zieht es sich weiterhin den internen Servernamen exchange.domain.local

Windows Updates sind Stand Mitte Dezember

Exchange ist Version 14.3 (Build 123.4)