Beiträge von riawie

    schau mal bei einem Nutzer der suchen kann und bei dem betroffenen Nutzer ob sich Einstellungen > Global > Outdated > "Konventionelle Suchfunktion anstatt Datenbank-Suche" unterscheiden.

    Wenn ja und wenn bei einem von denen die suchen können der Haken gesetzt ist und bei dem der nicht suchen kann nicht, dann erst mal als quickfix den Haken setzen, anschließend gucken was mit der Suchdatenbank los ist.

    Wenn es bei der Einstellung keine Unterschiede gibt wäre es relevant zu sagen wie die Einstellung bei Euch ist und man müsste mit dieser Info weiterschauen woran es denn bei dem einen Nutzer liegt das er nicht suchen kann.

    Ja. der Communication Controller ist im Grunde Legacy und wird nicht mehr aktiv beworben.
    Am Leben halten müssen sie ihn mit der bestehenden Funktionalität aber weiterhin, weil viele der internen Abläufe beim Fax und Voicemail Empfang schlicht davon abhängen und es viele alte Kunden gibt die das damals als es noch aktiv beworben wurde implementiert haben und seit dem immer noch aktiv nutzen. Bevor die das komplett rauswerfen machen sie es eher fit für die Zukunft mit SIP und Co. Bedingung um das am SIP Anschluss nutzen zu können ist halt das man eine DSP Karte hat welche sich um die Verarbeitung der tatsächlichen Audiosignale kümmert. Das Problem haben aber alle IVR Lösungen welche heutzutage per SIP angebunden werden sollen, weswegen z.B. der Käufer von den Eicon Diel Diva ISDN Karten die Diva Serie inzwischen auf Wunsch auch ganz ohne ISDN Ports anbietet und selbst die alten Karten teils für diese Zwecke unterstützt ;)

    Ob ich mich heutzutage noch mal an eine IVR Warteschlangen Implementation mit David machen würde kann ich auch nicht sagen, kommt halt auf die Rahmenbedingungen an, wenn das Setup klein ist oder am Ende eh auch zum Teil UMS Voiceboxen des David angesprochen werden sollen, wahrscheinlich aber durchaus schon noch ;)

    Viele derartige Probleme lassen sich mit einem Loopback bzw FullNat im Router umgehen, der schickt Anfragen von intern mit der eigernen externen URL in den eigenen Router über die Portweiterleitung im eigenen Router zum ensprechendem (Ziel-)Gerät.

    Nur weil das geht bedeutet das allerdings nicht das dieser Workaround sauberer wäre als eine korrekt aufgesetzte Split-DNS Umgebung ;)

    Und wenn man sein Split-DNS sauber aufsetzt ist das am Ende auch keine Verwirrung ;)

    Split DNS kann auch schnell zur allgemeinen Verwirrung beitragen. Ist ja auch ein wenig getrickst. Nur weils geht muss ichs ja nicht unbedingt machen.

    Denn Split DNS ist ganz anders als Full-Nat eben gar nicht getrickst.

    Wenn man Split-DNS in so einer Situation vermeiden und wirklich sauber arbeiten will lässt man Geräte die sich auch extern herumtreiben auch nie wirklich ins interne Netz, sondern immer nur in eine Mobile Devices DMZ von wo aus sie immer durch die innere Firewall auf interne Dienste zugreifen müssen, in dem Fall haben sie allerdings auch keine Notwendigkeit für ein Split-DNS oder ein Full-NAT.

    Wer allerdings gerne mal den Postlagernden Versand des David Servers nutzt tut dennoch gut daran Split-DNS korrekt aufzusetzen und den https Porst seines David Servers intern gleich zu konfigurieren wie von außen, denn sonst wird es umständlich und erfordert Handarbeit (oder eben so einen Workaround wie Full-NAT) sich intern mal fix die postlagernden Anhänge anzuschauen, was besonders doof bei Nachrichten ist welche auch einen internen Empfänger haben, der die Nachricht nicht nur zur Kenntnis, sondern die Anhänge öffnen können soll. (wären es nur interne Empfänger würde man ja auf Postlagernd ganz verzichten, ist aber auch nur ein externer dabei der das zwingend erforderlich macht muss man die Pille halt schlucken, aber das nur am Rande bemerkt ;) )

    Zusammenfassend:
    Full-Nat ist eigentlich der größere Hack, der manchmal allerdings einfacher einzurichten ist, wenn man in seiner Umgebung schlicht kein Split-DNS einrichten kann und sollte daher auch nicht als "bessere" Lösung für Fehler beim einrichten einer Split-DNS Umgebung propagiert werden ;)

    Wenn es von extern geht, von intern aber nicht hast Du ein Problem mit Deinem split DNS und nicht mit dem Autodiscover.

    Das Autodiscover dient eh nur dazu beim ersten einrichten eines Clients die Tipperei zum Teil zu ersparen.

    Daraus ergibt sich auch, das wenn Du 8443 beim internen Zugriff nutzen willst, du es natürlich auch beim Zugriff von extern tun musst wenn sich ein und das selbe Gerät abwechselnd intern oder extern befinden kann.

    Die nächste Frage wäre ob Du Den SRV Eintrag auf Deinem Split DNS für intern ebenfalls eingerichtet hast?

    zapp das Thema hatten wir die Tage erst hier im Forum.

    Es gibt von Tobit einen Hotfix zu dem Thema, Zitat:

    Hotfix david Client

    ===================

    Nach Installation des david Rollout 330 konnte es vorkommen, dass ohne

    Internet Verbindung das Ummmelden im david Client PC nicht mehr

    funktionierte. Außerdem konnte es zu einem Problem beim Export von eMails

    als EML Datei kommen, wenn es keinen Dateizugriff auf den david Server gibt.

    ZitatEnde

    Der Hotfix kann im SiteCare unter Software > Downloads > Packages als Hotfix david Client (nur Rollout 330) heruntergeladen werden, man erhält dann die Datei hfv128nt.exe

    UKe ein anderes cooles Tool in dem Zusammenhang ist icacls

    https://docs.microsoft.com/de-de/windows-…commands/icacls

    Die wichtigsten Befehle dafür: Auf dem alten David Server einmal alle ACLs sichern:

    icacls C:\Programme\David /save C:\Temp\ACL-David-Sicherung /t /c /l /q

    Dem Administrativen Nutzer mit welchem man sich künftig am neuen David Server anmeldet die notwendige Rechte (Vollzugriff) geben um die David Archiv Struktur bearbeiten zu dürfen:

    icacls C:\Programme\David /grant WindowsDomäne\Adminnutzername:(F) /t /c /l /q

    Nun die ACL-David Sicherungs-Datei von oben auf den neuen Server übertragen und in einen ordentlichen Texteditor werfen. mit dem dann mal alle auf dem neuen Server nicht passenden SIDs des alten Servers gegen auf dem neuen Server gültige SIDs per suchen und Ersetzen ausgetauscht werden.

    Zu guter Letzt noch alle ACLs wieder auf die David Struktur anwenden:

    icacls C:\Programme\ /restore C:\Temp\ACL-David-Sicherung-angepasst /t /c /l /q

    Mit icacls ist natürlich auch noch mehr möglich ;)

    Insgesamt hat Microsoft durchaus ne Menge gute Tools, welche allerdings oft nicht sehr weit bekannt sind ;)

    Ich hab mir das lange nicht mehr angeguckt, aber prinzipiell sollte der David Server nach wie vor auch ein vollwertiges IVR abbilden können.

    Wenn Du in Google nach "DVISE Scripting" suchst solltest Du ein PDF zu David 6.6 finden, das ist zwar steinalt, aber grundsätzlich sollte es Bestand haben, wenngleich vielleicht das ein oder andere im aktuellen David Server inzwischen etwas verändert wurde.

    In jeder vollständigen David Installation findet man auf dem Server über das Startmenü das Programm:
    "David(R) Communication Controller"

    Das PDF beschreibt letztlich wie man mittels diesem ein umfassendes IVR (Interactive Voice Response) System einrichten kann.

    für den Fall das komplexe Berechtigungen vorgefunden und auf den neuen Server transferiert werden müssen werden empfehle ich sich vorab mit subinacl von Microsoft zu beschäftigen:

    https://social.technet.microsoft.com/wiki/contents/…permission.aspx

    Wenn man die SIDs auf dem alten Server nachschauen kann lassen sich mit dem Tool nach dem übertragen auf dem neuen Server recht fix die alten SIDs in dort gültige neue SIDs ändern.

    Das bedingt alles ein wenig Vorarbeit und Planung, führt allerdings wenn man sich die Mühe macht zu minimaler Downtime für die Nutzer des Servers den man da umzieht ;)

    Aber es soll ja auch Leute geben die gar das Migrationstool von Tobit nutzen und die damit verbundenen Downtimes bzw. Zeiten bis alle Daten wieder voll verfügbar sind in Kauf nehmen ;) (Gleiches gilt im wesentlichen auch beim Restore aus einer StrongBox Sicherung...wenn auch mit leicht anderem Timing)

    Im Grunde Ja

    Nur würde ich die Archive nicht via Strongbox übernehmen sondern schlicht direkt beim kopieren des David Verzeichnisses mit kopieren.

    Wie man das am schnellsten und mit der geringsten Downtime vom alten auf den neuen Server übertragen kann hängt dabei ein wenig von Eurer aktuellen Installation ab und auch von der Datenmenge über welche wir sprechen.

    Im Zweifel schnappt man sich ein SSD, steckt das in den alten Server und kopiert dort den gesamten David Ordner in ein frisches NTFS, anschließend hängt man das SSD an den Hyper-V Host, bindet das SSD dort direkt als physische Platte in die Hyper-V VM ein und kopiert die Daten dann dort noch einmal an ihr endgültiges Ziel.

    Alternativ kann man auch gleich auf dem Hyper-V Server einen Freigabeordner erstellen, das VHD Image der künftigen VM dort temporär hinein verschieben und diese VHD dann am alten David Server aus der Freigabe heraus mounten um dann das gesamte David Verzeichnis direkt an seinen endgültigen Platz zu kopieren. Wenn man zum kopieren Windows Konsolen Bordmittel wie xcopy oder robocopy (je nach persönlicher Vorliebe) nutzt kann man das kopieren auch im laufenden Betrieb starten, hat damit schon mal einen nicht ganz aktuellen Stand, beendet dann die David Dienste und kopiert nun noch einmal alle vorher nicht kopierbaren sowie alle sich seither verändert habenden Dateien und eben die neu dazugekommenen ans Ziel.

    Anschließend die VHD am alten Server wieder aushängen, auf dem Hyper-V Host wieder an ihren Platz zurückschieben, die VM starten, eventuell noch Besitzrechte an der Verzeichnissstruktur anpassen, David drüber installieren und starten.

    Insgesamt setzt das ganze natürlich voraus das beide Server Mitglied der gleichen AD Domäne sind, sonst hat man hinterher noch einiges an Arbeit mit dem korrigieren der Verzeichnissrechte.
    Wobei es da - bei nicht zu komplexen Installationen - durchaus reichen kann den David Server einfach mal die Verzeichnissrechte zurücksetzen zu lassen.
    Bei meinem letzten Umzug hab ich alle Rechte im Anschluss an die Migration mit Windows Konsolen Bordmitteln alle SIDs in den ACLs aller Verzeichnisse und Dateien umschreiben lassen, weil wir hier sehr viele individuelle Rechte eingeräumt haben, aber auch das ist letztlich kein wirklicher Beinbruch und kann zum großen Teil dann sogar noch im schon wieder angelaufenen Betrieb erledigt werden.

    Die Installation welche ich so zuletzt - allerdings von Physisch auf Physisch - umgezogen habe hat 2 TB an Daten in ihren Archiven, die gesamte Downtime lag bei unter 2 Stunden, eben weil ich das kopieren der Daten - in dem Fall mehrfach - während des Live Betriebs habe laufen lassen bevor es dann einen finalen Kopiervorgang der neuen und geänderten Dateien gab.

    EckiD so lange die Installation auf dem alten, wie auch die temporäre Installation auf dem neuen Server mit Standard Pfaden - oder gleichen Pfaden - gelaufen ist hätte sogar der David nicht deinstalliert werden brauchen.

    Ich habe die IP immer zusammen mit dem Servernamen übernommen, prinzipiell dürfte die IP jedoch kein Problem darstellen, wenn Euer DNS denn sauber ist und nach dem Umzug zuverlässig den Servernamen sauber auf die neue IP auflöst.
    Wenn es da später irgendwo hängt findet man es allerdings leicht heraus so man dran denkt das der neue Server eventuell nur deswegen von einem Client nicht erreichbar ist (Firewall und Remotezugriff bedenken ;) )

    Die David Installation umzuziehen ist ja nun kein Ding wenn man den Servernamen beibehält.
    Da würde ich stets den Weg gehen den Zielserver auf seiner Zielplattform (egal ob nun Hardware oder VM) frisch aufzusetzen um möglichst wenig Altlasten mitzuschleppen.
    Dann die alte David Installation auf den neuen Server kopieren, bzw. verschieben, dabei die gleichen Pfade wie auf dem alten Server beibehalten, den alten Server außer Betrieb nehmen, den neuen Server mit dem alten Namen ausstatten, anschließend auf dem neuen Server einmal die David Installation in der gleichen Version wie sie auf dem alten lief drüber laufen lassen und fertig ist die Laube.
    Wenn man dabei Ports ändern will kommt das noch im Anschluss, aber ansonsten war es das auch schon.

    Eine P2V Migration eines bestehenden Windows Server Installation würde ich nicht machen, schon gar nicht wenn alternativ die Chance besteht gleich den move auf die aktuelle Version durchzuführen.

    Das Hotfix kann bereits im SiteCare unter Software > Downloads > Packages als Hotfix david Client (nur Rollout 330) heruntergeladen werden, man erhält dann die Datei hfv128nt.exe

    Es ist also keine Einzelanfrage per Intercom mehr nötig ;)

    Hotfix david Client

    ===================

    Nach Installation des david Rollout 330 konnte es vorkommen, dass ohne

    Internet Verbindung das Ummmelden im david Client PC nicht mehr

    funktionierte. Außerdem konnte es zu einem Problem beim Export von eMails

    als EML Datei kommen, wenn es keinen Dateizugriff auf den david Server gibt.

    Im Tobit SiteCare liegen unter Software > Downloads > Packages mittlerweile zwei Hotfixes für 330 bereit, einer für den Client (hfv128nt) und einer für den Grabbing Server (hfv129nt.exe)

    Hotfix david Client

    ===================

    Nach Installation des david Rollout 330 konnte es vorkommen, dass ohne

    Internet Verbindung das Ummmelden im david Client PC nicht mehr

    funktionierte. Außerdem konnte es zu einem Problem beim Export von eMails

    als EML Datei kommen, wenn es keinen Dateizugriff auf den david Server gibt.

    Hotfix david Grabbing Server

    ============================

    Nach Installation des david Rollout 300 konnte es vorkommen, dass per Grabbing

    Server keine eMails mehr abgeholt wurden. Das ist hiermit behoben.