Probleme mit Scan2Folder bei Serverumstellung…

Bei der Serverumstellung eines Kunden bin ich auf ein Problem beim Scannen auf ein Fileshare gestoßen. Der Kunde hat von einem SBS auf einen Server 2012 migriert. Eigentlich hatte ich erwartet, dass ich nur den Pfad im Scanner anpassen muss. Leider meldete das Gerät beim Scannen nur einen Verbindungsfehler, ohne weitere Details.

Nach meherer Prüfungen, ob das Fileshare von der Berechtigung her passt und ob der Servicebenutzer korrekt auf dem Scanner eingerichtet war, konnte das Problem einfach nicht gelöst werden. Nach einiger Recherche bin ich darauf gekommen, dass es am Port liegen muss. Von Werk ist dieser bei dem Scanner Port 139; es muss jedoch Port 445 sein.

Es handelte sich um ein Kopiersystem NRG Ricoh irgendwas; älteres Teil. Das Problem ließ sich lösen, indem wir uns per Telnet auf das Gerät geschaltet haben und folgende Einstellungen auf der Konsole getätigt haben:

smb client auth 1
smb client port 445

Windows 10 Creators Update 1703 und Datev…

Die Datev rät ausdrücklich vom Creators Update ab. Wie in Erfahrung gebracht werden konnte, gibt es Verträglichkeitsprobleme mit Datev Programmen, die z.Z. noch mit Microsoft abgeklärt werden.

Welche Probleme das sind, ist leider noch nicht bekannt. Bisher habe ich auch noch von keinem unserer Kunden von Einschränkungen gehört. Update folgt! Schöne Feiertage!

Update: Einige Datevplugins in den Eigenorganisations Programmen und Viwas verursachen Systemabstürze (Blue Screen), die zu Datenverlust führen können.

Shadowprotect SPX: Fehler bei Anmeldung…

Nachdem ich bei einem Kunden Shadowprotect SPX installiert habe, konnte ich mich nicht an der Konsole anmelden.

Connection failed. Please verify that the SPX service is running and
that the IP address and port are correct.

Ok, vielleicht hat der Installer die remote cli nicht korrekt installiert. Also neu registrieren mit spx_cli remote –enable 13581. Dabei erhielt ich folgende Fehlermeldung.

HTTPS Connection to ../version failed with error Cannot Connect:
Connection to 'https://127.0.0.1:13581/spx/version/' failed:
HTTPSConnectionPool(host='127.0.0.1', port=13581): Max retries
exceeded with url: /spx/version/ (Caused by ProxyError('Cannot
connect to proxy.', error('Tunnel connection failed: 503 Service
Unavailable',))).

Ja, da war was; der Kunde hat einen Proxyserver im Einsatz. In den Proxyeinstellungen des Servers müssen in den Ausnahmen localhost und 127.0.0.1 eingetragen werden. Anschließend funktioniert die Anmeldung in Shadowprotect SPX.

Outlook 2010 / Exchange 2016: Fehler bei Einrichtung des Postfachs

Nachdem ich einen neuen Exchange 2016 installiert habe, als Ablöse von David Tobit, gab es Probleme beim Einrichten der Postfächer unter Outlook 2010.

Der Name kann nicht aufgelöst werden. Es steht keine Verbindung mit
Microsoft Exchange zur Verfügung. Outlook muss im Onlinemodus oder
verbunden sein, um diesen Vorgang abzuschließen.

Lt. Microsoft gibt es hier einen Fehler bei der Anmeldung am Active Directory. Offenbar wird der Katalogserver nicht gefunden. Um das Problem zu lösen, wird ein Fixtit bereit gestellt. https://support.microsoft.com/en-us/help/319206/how-to-configure-outlook-to-a-specific-global-catalog-server-or-to-the-closest-global-catalog-server

Da bei dem Kunden vermutlich alle Benutzer von dem Problem betroffen waren, musste ich den Vorgang automatisiert durchführen.

Dazu habe ich eine REG-Datei erzeugt mit folgendem Inhalt..

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Exchange]

[HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider]
"Migrated OAB"=hex:01,00,00,00
"DS Server"="dc.domäne.local"

…und diese per GPO verteilt. „DS Server“=“dc.domäne.local“ muss natürlich angepasst werden.

Anschließen lies sich Outlook wie gewohnt einrichten.

Heraufstufung eines DC bei SBS-Server schlägt fehl…

Bei der Migration eines SBS-Servers treten manchmal merkwürdige Fehler bei der Heraufstufung eines neuen DCs auf. Unter anderem hängt der Vorgang bei folgendem Status.

Das NTDS-Einstellungsobjekt für diesen Domänencontroller wird auf
dem Remotedomänencontroller DC.domäne.x erstellt...

Der Grund hierfür kann ein defektes Domänenadmin-Konto des SBS sein.

Damit die Heraufstufung eines neuen DCs funktioniert, reicht es, einen frischen Domänenadministrator zu erzeugen. Anschließend wird mit dem neuen Domänenadministrator die Heraufstufung durchgeführt.

Outlook Anywhere Exchange… Probleme mit normalemail.dotm und normal.dotm…

Beim Einsatz von Outlook Anywhere eines Kunden gab es immer wieder Probleme mit Outlook. Im Domänennetz lief die Anwendung ganz normal. Außerhalb des Firmennetzes jedoch fragte Outlook beim Schließen nach dem Speicherort für die normalemail.dotm. Anschließend starteten diverse Officeanwendungen nicht mehr.

Die Neuinstallation von Office beseitigte den Fehler leider nicht; genauso wie u.g. Reg-Schlüssel.

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Options\WordMail]
"ATUserAdded"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Options]
"DisableRobustifiedUNC"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Options]
"DisableRobustifiedUNC"=dword:00000001

Ursache dieser Fehlers war die fehlerhafte Umleitung der Profilordner. In einer Gruppenrichtlinie zeigten diverse Umleitungen auf einen nicht vorhandenen Pfad. Da der Kunde diese Einstellung weiterhin nicht mehr nutzen wollte, habe ich die Umleitungen auf den lokalen Benutzerprofilpfad eingestellt; Richtlinie einfach so löschen is nich!

Nachdem die GPO auf dem Client griff, tauchte der Fehler in Outlook nicht mehr auf, sobald sich der Benutzer außerhalb des Firmennetzwerks befand.

Update Cloud Station Server Version: 4.2.3-4385 beseitig Synchronisierungsfehler…

Synology hat am 02.03.2017 Version 4.2.3-4385 für Cloud Station Server veröffentlicht:

Auf dieses Update habe ich gewartet, da ein Kunde aktuell von den gefixten Problemen in Punkt 2,3 und 4 betroffen ist. Ob sich mit der Aktualisierung die Konflikte lösen lassen werde ich später berichten.

Update: Die Fehler scheinen mit dem Updates soweit behoben zu sein!

Exchange public Folder entfernen, quick and very dirty…

Ausgangssituation für dieses Vorgehen war ein Problem bei einem Kunden, den alten öffentlichen Ordner zu entfernen. Der öffentliche Ordner war auf einem Exchange 2007 eingerichtet, sollte aber komplett neu auf einem Exchange 2013 erstellt werden. Auf die Migration des Ordners sollte in diesem Fall verzichtet werden.

Die Erstellung eines neuen öffentlichen Ordners auf dem Exchange 2013 ließ sich nicht durchführen, da auf dem Exchange 2007 noch eine public Folder Datenbank aktiv war.

Der öffentliche Ordner bzw. die Datenbank auf dem Exchange 2007 ließen sich allerdings auf Teufel komm raus nicht löschen und der Exchange ließ sich deswegen auch nicht deinstallieren. Ursache diese Problems waren Replikationsfehler, die sich auf die Schnelle nicht auflösen ließen.

Man kann die Datenbank über die ADSI-Editor entfernen, indem man beim Verbinden mit dem Editor unter „Bekannten Namenskontext auswählen“ „Konfiguration“ auswählt.

Anschließen hangelt man sich nach /Configuration/Services/Microsoft Exchange/First Organization/Administrative Groups/Exchange Administrative Group/Servers/“Servername“/InformationStore/“Storage Group“ und löscht den Schlüssel CN=“Public Folder Database“. Dieses Vorgehen ist aber mit Vorsicht zu genießen, da er absolut unprofessionell ist und nur als letze Möglichkeit zu betrachten ist.

Die Datenbank für den Public Folder erscheint nun nicht mehr in der Exchange-Verwaltungskonsole und man kann einen neuen öffentlichen Order in der Exchange 2013 Verwaltung erstellen. Der Exchangeserver 2007 lässt sich jetzt zudem deinstallieren.

Fehler in Datev Eigenorganisation beim Drucken von Rechnungen nach Viwas Deinstallation…

Nach der Deinstallation von VIWAS durch die Datevprogrammdeinstallation kann es zu Problemen in der Datev Eigenorganisation kommen. Es erscheinen Fehler mit der Kennung #DK20382 und #36005F/9og13wix (Layout-Datenbank). Ursache des Problems ist lt. der Datev eine fehlerhafte Deinstallationsroutine von Mcafee. Es werden wohl nicht alle Registrierungsschlüssel sauber entfernt.

Die Datev stellt hierzu einen Patch zur Verfügung, den ich leider nicht veröffentlichen darf. Man muss sich also direkt an die Datev wenden bzw. an den Systempartner.

Aus lizenzrechtlichen Gründen dürfen Sie diese Datei nur lokal an Ihrem
System verwenden. Eine Vervielfältigung und/oder Veröffentlichung der Datei
oder des Links ist nicht gestattet. Bitte löschen Sie das Update-Paket nach
erfolgter Reparatur unverzüglich und endgültig von Ihrem System
(z.B. Download-Verzeichnis, Temporäres-Verzeichnis, etc.).

Der Patch muss installiert werden und die aktuellen Signaturen müssen geladen sein. Nach einem Neustart des Server wird Mcafee wieder über die Systemsteuerung deinstalliert.