Jump to content

Candy

Members
  • Gesamte Inhalte

    254
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Candy

  1. Ja. Es macht sich das Gefühl breit das der Helpdesk, in welcher Stufe auch immer, gar nicht mehr weiss was dort technisch passiert.

    Fazit ist, die Backup Strategie mehrfach zu überdenken u. anzupassen.

    Das mal ein Dienst, oder eine Anwendung in der „heilen MS365 Welt“ nicht funktioniert ist ja technisch völlig normal. Das haben wir bei on premise Systemen genauso. Aber das durch den AD Connect aktiv Benutzer gelöscht werden hat eine neue Dimension!

    Kaum auszudenken wenn wir eine bidirektionale Synchronisierung gehabt hätten. Das vielleicht restliche technische Vertrauen in MS365 ist dahin.

    Einfach nur verrückt. 

  2. Hallo Community,

     

    wie immer hoffe ich auf euer „Schwarmwissen“ und bedanke mich im Vorfeld bei Euch!

     

    Kurz zu den Gegebenheiten.

    Microsoft Domain Umfeld. Viele virtuelle Server.
    Die Microsoft 365 Umgebung wird eingesetzt inkl. einem eigenständigen VM MS Server 2019 mit installierter Microsoft Azure AD Connect Anwendung.
    Der genannte MS Server 2019 hat nur die Aufgabe den AD Connect zu bedienen und synchronisiert nur in die MS 365 Welt (z.B. Kennwortänderungen).
    Der AD Connect läuft seit ca. 3 Monaten.

     

    Am 01.11.23 haben wir damit begonnen, für alle Mitarbeiter die Multi Faktor Authentifizierung zu implementieren. Einen Benutzer nach dem anderen. Da auch einige Erklärungen für die Mitarbeiter dazu gehören.
    Am 01.11.23 haben wir 23 Mitarbeiter mit MFA technisch umgesetzt.
     

    Am 02.11.23 kam die erste Nachricht auf unserem „Notkanal“ das keine E-Mail Funktion mehr gegeben ist. Und das Unternehmen von extern nicht mehr erreichbar wäre (E-Mail).

    Wir schauten uns das MS 365 Admin Portal an und stellten erschreckend fest, dass alle Benutzer, 42 an der Zahl, gelöscht worden sind. Alle Benutzer befanden sich unter „gelöschte Benutzer“. Außer die Benutzer die nicht mit ADC synchronisiert werden ( reine Postfächer usw.).

    Wir stellten die gelöschten Benutzer wieder her und suchten parallel was dort passiert ist.
    Im log MS 365 stellten wir fest, dass um 4.39Uhr der AD Connect innerhalb von 1 sec alle 42 Benutzer gelöscht hat. In der AD hat sich nichts geändert.

    Support Ticket bei Microsoft eröffnet. Es gab ein Telefonat u. der MS Mitarbeiter schaute einmal mit auf das System. Seine Antwort war wie folgt:

     

    Vielen Dank für die Zusammenarbeit mit Microsoft Office 365 Support.  
    Die Serviceanfrage wird in unserem System archiviert. Sollten Sie weitere Fragen haben, diese könnte innerhalb der nächsten 7 Tage von portal.office.com wieder eröffnet werden. 
     
    Problembeschreibung: Wie telefonisch besprochen, das Problem war ein Sonderfall, der wegen der Aktivierung von MFA ausgelöst und von alleine im Server behoben wurde, allerdings passiert es nicht immer. Der Grund dieses Problems ist dass die Server aktuell einige Updates erfahren, was zu Vorfällen bei manchen Diensten führt, die man auch im Admin Center unter Dienststatus sehen kann, diese Vorfälle werden entweder von alleine behoben  

    oder unser Entwicklerteam arbeitet sofort daran, um sie zu lösen.  

    Lösungsschritte: Der Fall von alleine behoben 

     

    Natürlich geben wir uns mit der Antwort nicht zu frieden. Und haben beim angegebenen MS Manager nochmals eine Anfrage gestellt, um eine technisch plausible Antwort zu erhalten.
    Antwort steht noch aus...

     

    Habt ihr so etwas schon gehabt? Oder einen Ansatz was diesen “Delete ALL” Befehl ausgelöst haben könnte?

     

    Danke für eure Unterstützung!

  3. Hallo,

     

    nun hat sich dazu bei uns einiges geändert. Und ich dachte ich schreibe euch nun unseren Lösungsansatz u. Umgang.
    Vielleicht habt ihr auch noch andere Erfahrungen damit. :)

     

    1. Wir haben den AAD Connect umgesetzt. Auch aus dem Grund, um die Kennwort Synchronisierung für die Domain Welt u. MS365 Welt für alle MAs zu Verfügung zu stellen.

    2. Wir haben auf beiden Terminal Server Farmen nur noch Microsoft 365 Produkte installiert (keine Volume Lizenzen mehr)

     

    Dadurch beruhigte sich die ganze Problematik deutlich!  "Outlook lässt sich nicht öffnen" oder "Office Anmeldung klappt nicht"

     

    Was wir zwischendurch u. unregelmäßig aber immer wieder und nur auf den Terminal Server Farmen haben, sind nach Benutzer Kennwort Änderungen (alle X Tage), dass die MS365 Anmeldung dann schief geht und nicht genommen wird. Der ganze Synch Prozess AAD Connect usw. dauert natürlich eine Zeit, aber das haben wir berücksichtigt. Trotzdem können wir ungeduldige Mitarbeiter nicht ausschließen. :)

     

    Unsere Lösung dafür ist, der betroffene Mitarbeiter bleibt z.B. auf dem Terminal Server 1 angemeldet, beendet alle Office Anwendungen, wir löschen im Hintergrund die Datei     %APPDATA%\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy im betroffenen Benutzer Ordner auf dem Terminal Server 1.
    Danach meldet der Benutzer sich ab und wieder an. Dann greift sofort die MS365 Anmeldung. Maximal müssen noch einmal die Anmeldedaten eingegeben werden.

  4. Hallo in die Runde,

     

    Ja, es war ein Switch (HPE CX6100).  Paketverluste gingen in die 100.000de . Bei jedem weiteren "Copy Job" kamen tausende hinzu....
    Firmware usw. nochmals aktualisiert, aber gleiches Verhalten. Switch rausgeschmissen und seit ca. 21 Tagen haben wir vom Kunden keine Beschwerden mehr und konnten den Fehler auch nicht wieder nachstellen.

     

    Danke und viele Grüße

     

  5. Hallo in die Runde,

     

    leider habe ich mal wieder ein nicht nachzuvollziehendes Phänomen in einer Microsoft Windows Domain Umgebung. Im allgemeinen Internet habe ich dazu leider auch keine Antworten finden können.

    Umgebung:

    Rechenzentrum Colocation Windows Domain
    Anbindung Standort A LAN/ LAN Kopplung mit Hilfe von Fortigate. Anbindung 1Gbit/s up wie down
    Anbindung Standort B LAN/ LAN Kopplung mit Hilfe von Fortigate. Anbindung 1Gbit/s up wie down

     

    An Standort A u. B wird „gemischt“ gearbeitet, entweder auf einer Terminal Server Farm, oder auch lokal für Grafikbearbeitungen usw. Alle Client Endgeräte sind Mitglied in der Windows Domain.

    Nun das Phänomen, was ich mir noch nicht erklären kann.

    An Standort A, oder B ist ein Grafiker mit einer Workstation. Wenn er sich über eine Freigabe vom File Server normale Grafiken lokal auf seine Workstation kopiert. Als Beispiel Standard .jpg oder .png Grafiken, werden diese Grafiken verändert. Entweder sieht man nur noch das halbe Bild, oder die Farben sind vermischt oder, oder. Die Größe der Datei bleibt aber gleich.

    Das tritt ebenfalls auf, wenn z.B. ein WORD Dokument mit Grafikinhalt vom File Server geöffnet, oder lokal kopiert wird. Die Grafiken im WORD-Dokument werden verändert, sind nicht mehr erkennbar, oder mit Fehlern dargestellt.


    Irgendein Vorgang greift aktiv in die Datei und verändert Sie.


    Das passiert nicht immer u. nur sporadisch.

    Zusätzlich habe ich im Rechenzentrum einen kleinen Management PC der ebenfalls in der Domain eingebunden ist. Da habe ich genau das Gleiche Problem.

    Wird im Gegensatz auf der Terminal Server Farm gearbeitet. Gerne mit den gleichen Dateien und Grafiken, existiert das Phänomen nicht.

    Lokalen Virenschutz hatte ich Client seitig schon deaktiviert bzw. deinstalliert. Leider gleicher Effekt.

     

    Im Anhang eine Beispiel Grafik wie das aussieht. 

     

    Vorab, vielen Dank für Eure Hilfe.

    beispiel.JPG

  6. vor 18 Minuten schrieb mwiederkehr:

    Was wäre der Vorteil eines AAD Join? Kann der Server gleichzeitig in einer "legacy" und einer Azure-Domain sein, wenn diese nicht synchronisiert werden (kein AAD Connect)?

     

    Im verlinkten Artikel wird unser Problem leider nicht behandelt. Es äussert sich in folgenden Fehlern:

     

    AAD, Event 1097:

    Error: 0x80090011 Das Objekt wurde nicht gefunden.
    
    Das Objekt wurde nicht gefunden.
    
    Exception of type 'class WinRTException' at oauthtokenrequestbase.cpp, line: 733, method: OAuthTokenRequestBase::QueryTokenBindingKeyId::<lambda_384ba4be0f1ddecb55f87844038ccea6>::operator ().
    
    Log: 0x8aa5007f Unable to create a Token Binding Key.
    Logged at oauthtokenrequestbase.cpp, line: 733, method: OAuthTokenRequestBase::QueryTokenBindingKeyId::<lambda_384ba4be0f1ddecb55f87844038ccea6>::operator ().
    
    Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a
    
    Error: 0x8AA9004C Acquire token by refresh token failed, trying PRT.
    Logged at refreshtokenrequest.cpp, line: 79, method: RefreshTokenRequest::AcquireToken.
    
    Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a

     

    AAD, Event 1098:

    Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
    
    Das System kann den angegebenen Pfad nicht finden.
    
    Exception of type 'class WinRTException' at webaccountprocessor.cpp, line: 280, method: AAD::Core::WebAccountProcessor::ProcessBrokerBackgroundRequest::<lambda_c59055bd9d9c85aff79a2f7420694224>::operator ().
    
    Log: 0xcaa5001c Token broker operation failed.
    Operation name: GetTokenSilently
    Logged at webaccountprocessor.cpp, line: 545, method: AAD::Core::WebAccountProcessor::ReportException.
    
    Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
    Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.
    
    Log: 0xcaa10083 Exception in WinRT wrapper.
    Logged at authorizationclient.cpp, line: 224, method: ADALRT::AuthorizationClient::AcquireToken.
    
    Request: authority: https://login.microsoftonline.com/common, client: d3590ed6-52b3-4102-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c
    
    Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
    Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.
    
    Log: 0xcaa1007b Acquire token failed.
    Logged at authenticationcontext.cpp, line: 404, method: AuthenticationContext::AcquireTokenInternal.
    
    Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c
    
    Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
    Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.
    
    Log: 0xcaa1007b Acquire token failed.
    Logged at aggregatedtokenrequest.cpp, line: 69, method: AggregatedTokenRequest::AcquireToken.
    
    Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a

     

    Falls Du mehr weisst, bin ich dankbar für einen Tipp, da ja anscheinend die Deaktivierung von WAM nicht der Weisheit letzter Schluss ist.

    Moin,

     

    ich hatte parallel ein Support Ticket bei Microsoft eröffnet. Dort habe ich diesen Link zur Umsetzung erhalten.
    Für mich auf dem ersten Blick, aber auch der falsche Ansatz, da wir nicht mit diesen Office Versionen arbeiten, sondern mit Microsoft 365.
    Mit den Vorschlag von Microsoft bin ich auch nicht ganz glücklich/ unsicher und habe es noch nicht umgesetzt.

     

    How modern authentication works for Office 2013 and Office 2016 client apps - Microsoft 365 Enterprise | Microsoft Learn

     

     

  7. vor 23 Minuten schrieb Candy:

    Hallo mwiederkehr. Danke für deine Antwort! Was meinst du mit dem oberen Satz? Das Verzeichnis konnte ich so nicht finden.

    Diese Einträge habe ich gesetzt u. getestet. Nehme ich danach einen betroffenen Benutzer, kann ich diesen leider immer noch nicht anmelden.

     

    P.S. Ich habe nun einen betroffenen Benutzer, der kein Outlook mehr nutzen konnte, in WORD bei M365 abgemeldet. Danach wieder erfolgreich angemeldet und Outlook konnte auch wieder gestartet werden.

    vor 5 Minuten schrieb mwiederkehr:

    Das Verzeichnis befindet sich im Benutzerprofil unter „\AppData\Local\Packages“.

     

    Du hast die Registry-Keys schon unter dem entsprechenden Benutzerkonto gesetzt?

     

    Bei mir hat das Setzen der Keys gereicht, ich musste danach das Verzeichnis nicht löschen.

     

    Gefunden, wird Zeit für Feierabend! Ich Danke dir für die Hilfe. Somit haben wir erst einmal eine Option um zu reagieren, ohne das gesamte Profil neu zu erstellen.

  8. vor einer Stunde schrieb mwiederkehr:

    Das ist die App, die man im Profil unter Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy findet. Löscht man dieses Verzeichnis (der Benutzer darf dabei nicht angemeldet sein), funktioniert die Anmeldung wieder. 

    Hallo mwiederkehr. Danke für deine Antwort! Was meinst du mit dem oberen Satz? Das Verzeichnis konnte ich so nicht finden.

    vor einer Stunde schrieb mwiederkehr:

     

    In meinem Fall hat es geholfen, per Registry die bisherige Token-Verwaltung zu aktivieren:

    Windows Registry Editor Version 5.00
    
    [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
    "EnableADAL"=dword:00000001
    "DisableAADWAM"=dword:00000001
    "DisableADALatopWAMOverride"=dword:00000001

     

     

    Diese Einträge habe ich gesetzt u. getestet. Nehme ich danach einen betroffenen Benutzer, kann ich diesen leider immer noch nicht anmelden.

  9. Hallo Community,

     

    ich hoffe ich schreibe das hier im richtigen Abschnitt. :)
    Optisch hat sich hier wirklich viel verändert. Sieht sehr gut aus!
    Ich muss in Zukunft mal wieder regelmäßig hier vorbei schauen. :)

     

    Folgende Ausgangslage:

    1. Neue Microsoft Domain aufgesetzt
    2. Neue Microsoft Terminal Server Farm mit Hilfe von Microsoft Server 2019 aufgesetzt, als Benutzer Profilspeicher FS Logix im Einsatz.
    3. Alle Windows RD Benutzer besitzen eine Microsoft 365 Business Premium Lizenz(gesamt 51stk).
    4. Microsoft 365 Anwendungen wurden auf allen Windows Terminal Servern 2019 mit Hilfe des Microsoft Deployment Tool vorschriftsmäßig installiert. Die Lizenz ist auf allen Terminal Servern als „Mehrbenutzer fähige Lizenz“ hinterlegt u. registriert
    5. Beim ersten Start von Outlook 365 im Benutzer Kontext kommt ordentlich die Microsoft Benutzeranmeldung und das Postfach wird ohne Outlook Cache Mode dargestellt.

     

    Technisches Problem:

    Aus für uns noch unerklärlichen Gründen, bricht Microsoft Outlook 365, sporadisch bei unterschiedlichen Benutzern, täglich die Verbindung ab.
    Fehlermeldung:
    „Outlook kann nicht gestartet werden. Das Outlook Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Der Informationsspeicher steht nicht zur Verfügung.“

     

    Was haben wir zur Behebung versucht?

    Wir haben danach keinerlei Möglichkeit mehr, die Microsoft 365 Benutzer Anmeldung nochmals durchzuführen. Wir bekommen den Benutzer, den es betrifft, auf keiner uns technisch bekannten Weise wieder bei M365 angemeldet. Fehlermeldung bei Outlook 365 " Da hat etwas nicht geklappt"

    Auch das Löschen vom Outlook Profil mit wiederholten anlegen eines neuen Outlook Profils bringt die gleiche Fehlermeldung.
    Wir müssen das gesamte Microsoft Benutzerprofil löschen und wieder neu anlegen. Das funktioniert wenige Tage und wir stehen vor dem gleichen Problem.

    An allen Standorten haben wir sehr gute Internetanbindungen( 1GB/s up, wie down). Die gesamte DNS, Autodiscover usw. Konfigurationen sind alle grün und zeigen von Microsoft keinerlei Fehler an(online Test durchgeführt). Auch der lokale DNS Server löst alles ordnungsgemäß auf.

    Das Problem tritt bei den Benutzer nur auf der Terminal Server Farm auf. Nicht lokal in der Outlook 365 Installation.

     

    Die Migration vom on premise Microsoft Exchange Server wurde aus "politischen Gründen" komplett händisch u. mit Hilfe von Mail Store umgesetzt.

     

    Kennt vielleicht jemand diesen Fehler?
    Vielleicht Fehlerhafte Lizenz Abfragen von Microsoft?

     

    Vielen Dank für eure Unterstützung!

     

  10. Hallo Community,

     

    kurz zur Umgebung.
    Ein physischer leistungsstarker Server der mit Hilfe von VMware ein Microsoft SBS Server 2011 Standard und ein als Terminal Server fungierender Microsoft Server 2008 R2 Standard beinhaltet.

    Sauber lizenziertes Microsoft Office 2013 Standard für Terminal Umgebungen.

    Alle Microsoft Benutzer arbeiten über Exchange und Outlook 2013. Jeder hat seine benutzerbezogene E-Mail Adresse und jeder hat volle Rechte auf ein info@ „Raumpostfach“ von Exchange.

    Weil die Fehler der Mitarbeiter mit Hilfe der Technik eingegrenzt werden sollen und leider der „Klick“ auf das „Von Feld“ des Öfteren vergessen wird, ist die Vorgabe das das „Von Feld“ in Outlook automatisch bei jeder Tätigkeit, ob nun neue E-Mail, oder E-Mail Versand aus einer Warenwirtschaft automatisch mit dem info@ „Raumpostfach“ gefüllt wird.
    Somit soll der ständig auftretende Fehler behoben werden, dass die Mitarbeiter E-Mails mit der benutzerbezogenen E-Mail schreiben, oder beantworten.

    Was habe ich versucht?
    Ich habe ein wenig mit den Makros versucht diese Einstellung umzusetzen. Leider habe ich davon nicht wirklich viel Ahnung und bin nach den Anleitungen die ich gefunden habe vorgegangen.

    Unter VisualBasic in Outlook „Diese Outlook Sitzung“ habe ich den unten stehenden Text eingefügt und die Makro Einstellungen angepasst. Anhand der Makro Meldung beim Outlook Start sehe ich das das Makro greift. Aber leider wird das „Von Feld“ nicht mit den Vorgaben ausgefüllt. Die E-Mail Adresse ist entfernt.

     

    Oder ihr habt vielleicht einen ganz anderen Lösungsansatz für mich? Bin für alle Vorschläge offen. :)

     

     

     

    '***MAKRO FÜR automatische Absenderadresse***

     

    'Beim Erstellen einer neuen Nachricht wird das VON-Feld autom. mit dem Gruppenkonto ausgefüllt.

     

    'DEKLARATIONEN

    Private WithEvents m_Inspectors As Outlook.Inspectors

    Private WithEvents m_Inspector As Outlook.Inspector

     

    Private Sub m_Inspectors_NewInspector(ByVal Inspector As Outlook.Inspector)

        Set m_Inspector = Inspector

    End Sub

     

    'AUTOMATISCHES AUSFUELLEN DES VON-FELDES MIT DER GRUPPEN-E-MAIL-ADRESSE

     

    Private Sub m_Inspector_Activate()

        On Error GoTo Ende 'Verhindert, dass beim Öffnen anderer Outlook-Klassen (z.B. Kontakte) Fehler angezeigt werden

        If m_Inspector.CurrentItem.SentOnBehalfOfName = "" Then 'Wenn Absenderfeld leer, dann...

            m_Inspector.CurrentItem.SentOnBehalfOfName = "E-Mail Adresse" '...Name des Absenders hinzufügen...

            m_Inspector.CurrentItem.BCC = " " 'Hilfsanpassung, da Absender sonst nicht hinzugefügt wird

        End If

        Set m_Inspectors = Application.Inspectors

    Ende:

    End Sub

     

    'AUTOSTART

    Private Sub Application_Startup()

        'Inspector für Automatisierung Absenderadresse

        Set m_Inspectors = Application.Inspectors

    End Sub

     

     

    Danke für eure Unterstützung!

  11. Hallo,

     

    ich bin auf der Suche nach einem "syslog Viewer" der mir vorhandene syslog Dateien ordentlich auswerten kann.
    Im Einsatz habe ich eine QNAP TS853U-RP die einen syslog Server mitbringt und diverse Netzwerkgeräte ihre Syslog Dateien dort ablegen. Nun habe ich schon diverse Tools getestet, aber irgendwie war das alles nicht das pssende für eine vernünftige Auswertung. Nun ist mein Gedanke das einer von euch vielleicht schon gute Erfahrung mit einem bestimmten syslog Auswerter gemacht hat.
    Kann natürlich auch gerne Geld kosten, wenn ich es vorher testen kann.

     

    Danke für eure Unterstützung!

     

  12. Spiceworks stammt aus einer Community von IT begeisterten Leuten wie du und ich. Und um das Geld geht es gar nicht. Qualität kostet Geld, das ist bekannt.
    Die Art und Weise begrüße ich einfach!
    Schaust dir am Beispiel der Cebit an, kleiner Spiceworks Stand der von Jahr zu Jahr etwas größer wird mit begeisterten IT'lern die auf jede Frage eingehen und dadurch eine Software am wachsen ist die durch die Vorschläge und Beiträge der Fans immer weiter ausgebaut wird.
    Irgend wann wird das deutlich Geld kosten und richtig vermarktet werden,. aber das ist der richtige Weg ein Software Produkt entstehen zu lassen.

    Auch bei Dokusnap schauen wir jedes Jahr vorbei, aber das ist eben eine andere Welt/ Strategie. Das Produkt ist Klasse und wurde auch von uns gekauft, nur nach den Folgekosten nicht weiter verfolgt. Weil der Kosten Nutzen Faktor in unserem Fall nicht mehr passte. Und da gab es auch keinen Spielraum.
    Deswegen ist es Quatsch zu behaupten das es um "Geiz ist geil" geht. Im Saturn war ich schon lange nicht mehr.

     

    Also, alles gut und wie gesagt nur meine Meinung und Erfahrung. :)

     

  13. Hallo,

     

    persönlich haben wir auch schon Dokusnap im Einsatz gehabt. Ganz ehrlich gesagt waren die Kosten für zusätzlichen Funktionen/ Module oder auch Microsoft Visio in den früheren Versionen einfach zu heftig.

     

    Was mich persönlich bis heute sehr überzeugt hat ist "SpiceWorks"
    Die eingeblendete Werbung ist etwas nervig, aber akzeptabel im Gegensatz zu 0€ Einkaufspreis, oder ca. 300$ um die Werbung zu entfernen.
    Die Übersichtlichkeit und vor allem was alles ausgelesen werden kann ist bis heute sehr überzeugend(Statusinformationen Garantie Hardware usw.).
    Auch der HelpDesk mit Ticket System ist ein sehr guter Ansatz. Noch nicht ganz ausgereift aber das kann noch werden.

  14. Hallo,

     

    ja, natürlich an einem anderen Standort. Da habe ich mich etwas falsch ausgedrückt. :)

    Ich habe mich jetzt in der Absprache mit einem "Kollegen" dazu entschlossen am 2. Standort die bestehende FritzBox rauszuwerfen, eine Zywall USG20W zu installieren und einen direkten SSL VPN Tunnel zwischen den Standorten aufzubauen.
    Unsere Vermutung ist, dass Microsoft das über RDP und der virtuellen Schnittstelle(Zywall SecuExtender) die auf dem Client PC installiert ist, nicht kappiert das Druckgerät "anzusprechen".
    Dazu kommt noch das es für das Druckgerät keine PCL Treiber gibt, also kein Business Gerät im weiteren Sinne dar stellt und die ganze jetztige Konstellation etwas "unglücklich" ist.
    Ich hoffe das ich damit Ruhe in das Thema bekomme.

  15. Hallo Community,

     

    kurz zur Schilderung;

     

    im Hauptbüro 5 Arbeitsplätze(Wind7Pro64bit) und ein Server SBS 2008 der als DomainController eingesetzt wird und eine Zyxel USG60W als Hardware Appliance.

    In einem weiteren Büro ein Arbeitsplatz(Win7Pro64bit), der nicht Domainmitglied ist, sondern sich über eine SSL VPN ins lokale Netzwerk des Hauptbüros einwählt(über die Zyxel) und danach via RDP an einem PC im Hauptbüro arbeitet. Auf dem PC der im Hauptbüro steht und an dem via RDP gearbeitet wird, ist der aktuelle Treiber des Druckgerätes aus dem zweiten Büro installiert.

    Steht die RDP Sitzung wird der "umgeleitete" Drucker auch "sauber und bereit" angezeigt, aber er druckt nicht.
    Es passiert gar nichts, weder Fehlermeldung noch sonstiges. Der Testdruck ist auch in der Druckerwarteschlange nicht mehr zu sehen.

    Das Druckgerät im zweiten Büro ist über Netzwerk und nicht über USB angeschlossen. Kann das vielleicht noch den Fehler verursachen?

     

    Für einen Tipp wäre ich euch sehr dankbar.

     

    Danke für eure Unterstützung!

  16. Hallo,

     

    leider habe ich beim durchsuchen des Forums nur Lösungsvorschläge für Exchange 2003 gefunden.

     

    Problem:

    1. Exchange sendet gar keine Anhänge mit.
    2. Exchange sendet nicht den eigentlichen Anhang, sondern eine winmail.dat.

    Die Umgebung; Small Business Server 2011 in Verbindung mit Outlook 2013 auf allen client PCs. Alle client PCs Win7.

     

    Ich finde in der Exchange Managment Konsole leider keine Konfigurationseinstellung um das Rich Text Format zu beeinflussen.

    In der Firma werden viele Rechnungen via E-Mail versendet(pdf Format, Anhang E-Mail). Und die Beschwerden sind seit Einsatz des neuen Servers extrem in die Höhe gegangen..

     

     

    Danke für eure Unterstützung.

     

×
×
  • Neu erstellen...