NIERO@net e.K. – Corporate Blog

Wir sichern Ihre digitalen Unternehmenswerte!

2 Supportfälle–2 Lösungen (Windows Search & Business Contact Manager 2010)

Manche Probleme erscheinen so unbedeutend und sind dann so arg schwer zu lösen. Aber gut….

Situation 1(Business Contact Manager 2010): Kurz die Ausgangslage:  Microsoft Office 2010 Pro Plus 32Bit SP1 auf Windows 7 Ultimate 64Bit SP1 mit dem Business Contact Manager 2010 SP1 installiert.

Kurzzeitig war die Microsoft Office 365 Preview Enterprise side-by-side installiert und wurde aufgrund von Fehlermeldungen über inkompatible add-ins wieder entfernt und auf eine virtuelle Maschine verschoben.

Danach war es weder aus Word oder Excel noch aus dem BCM selber möglich ein Dokument mit einem Kontakt zu verknüpfen. Die (übliche) Fehlermeldung war “BCM konnte die letzte Aktion nicht abschließen”.

Das Logfile ergab:

21.10.2012 08:06:06: Logging initialized.
[V] [15:10:34.7281667]Microsoft.BusinessSolutions.eCRM.OutlookAddIn.CSUtils: Protokollierung beginnen
[V] [15:10:40.3442747]BusinessLayer: ReattachOldDatabases: Enter
[V] [15:10:43.0899275]Microsoft.BusinessSolutions.eCRM.OutlookAddIn.CSUtils: FIRSTUSE: Configuring offline
[E] [15:10:43.1679290]BCMRes: Das COM-Objekt des Typs "Microsoft.Interop.eCRM.Outlook.NameSpaceClass" kann nicht in den Schnittstellentyp "Microsoft.Interop.eCRM.Outlook._NameSpace" umgewandelt werden. Dieser Vorgang konnte nicht durchgeführt werden, da der QueryInterface-Aufruf an die COM-Komponente für die Schnittstelle mit der IID "{00063002-0000-0000-C000-000000000046}" aufgrund des folgenden Fehlers nicht durchgeführt werden konnte: Bibliothek nicht registriert. (Ausnahme von HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).
[E] [15:10:43.1679290]BCMRes:    bei Microsoft.Interop.eCRM.Outlook.NameSpaceClass.get_Application()
   bei Microsoft.BusinessSolutions.eCRM.OutlookAddIn.CSUtils.BcmStoreCommon.RefreshFormRegionDefinition(String messageClass)
   bei Microsoft.BusinessSolutions.eCRM.OutlookAddIn.CSUtils.FirstUse.FirstUseWorker.DoFirstUsePipeline(Object state)

Durchgeführte Schritte:

  • Office repariert= keine Lösung!
  • BCM repariert = keine Lösung!
  • Cache gelöscht = keine Lösung!
  • HKEY_CURRENT_USER\Software\Microsoft\Business Solutions eCRM gelöscht = keine Lösung!
  • SQL-Einstellungen und Permissions überprüft (Netzwerkdienst mit Vollzugriff auf den Ordner DATEN und die Datenbank MSSmallBusiness) = keine Lösung!
  • BCM deinstalliert und Datenbank neu erstellt = keine Lösung!
  • Outlook-Profil neu erstellt = keine Lösung!
  • Microsoft Office 2010 PIA repariert = keine Lösung!

Eine längere Recherche ergab dann Hinweise auf einen Zusammenhang mit der Microsoft Office 365 Preview und deren PIA.

Also haben wir uns den lokalen GAC angeschaut und mit Überraschung festgestellt, dass die PIA von Office 15 alle noch auf dem System vorhanden waren.

Aus dem Ordner selber waren sie nicht zu löschen. Es gibt von Microsoft in der MSDN ein Tool zur Entfernung von .NET-Assemmblies aus dem GAC, dies verlangt aber die vollständigen Namen als Liste oder Einzeln, genau so, wie sie im GAC erscheinen. Bei 15 Stück erschien mir das zu aufwendig.

In dem Zusammenhang stießen wir aber auf einen MSDN-Thread, in dem ein Entwickler fragte, wie er denn eine korrupte Excel2013-PIA wieder loswerden könne.

Die Lösung war die entsprechenden Einträge unter dem HKEY_CLASSES_ROOT\TypeLib zu löschen, die sich auf Office 15 beziehen!

Problem gelöst!

Situation 2 (Windows Search): Ausgangslage: Windows 7 SP1 (64Bit). Die unterstützten Ordner im Benutzerprofil wurden auf unterstützte Weise auf eine andere Partition verschoben.

Windows Search ergab unvollständige bis gar keine Ergebnisse.

Durchgeführte Schritte:

  • Index neu erstellt = keine Lösung!
  • Windows Search deinstalliert und nach reboot neu installiert = keine Lösung!
  • Unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search den Wert von SetupCompletedSuccessfully von 1 auf 0 gesetzt und Maschine neu gestartet = keine Lösung!
  • Permissions der betroffenen Dateien und Ordner überprüft (SYSTEM und das Konto, welches den Suchvorgang durchführt, brauchen Vollzugriff auf die zu indizierenden Orte) = o.k.!
  • Kontrolle, ob bei den betroffenen Ordnern und Dateien unter “Erweiterte Attribute” das Häkchen bei “Zulassen, das für Dateien in diesem Ordner Inhalte zusätzlich zu Dateieigenschaften indiziert werden” gesetzt ist = o.k.

An der Stelle kommen zwei interessante Beobachtungen:

  • betroffene Orte aus den zu indizierenden Orten entfernt = Dateien werden (wenn auch langsam) und unter Hinweis, wir sollten den Ort zum Index hinzufügen, gefunden!
  • betroffene Orte wieder zum Index hinzugefügt = keine Ergebnisse!
  • betroffene Orte inkl. Inhalte an ihren ursprünglichen Speicherort zurück verschoben = Index funktioniert!
  • betroffene Orte inkl. Inhalte wieder auf das zweite Volumen verschoben = Index funktioniert nicht mehr!

Uns fiel dann zufällig ein, was wir über die NTFS-Attribute gelernt haben, wenn Ordner und Dateien entweder kopiert oder verschoben werden.

Aufgrund dieser Eingebung haben wir bei den betroffenen Ordnern und Dateien unter “Erweiterte Attribute” das Häkchen bei “Zulassen, das für Dateien in diesem Ordner Inhalte zusätzlich zu Dateieigenschaften indiziert werden” entfernt und die Frage, ob dies für alle Ordner und Dateien im betroffenen Ordner übernommen werden soll, mit “Ja” bestätigt.

Nach Abschluss dieses Vorgangs haben wir das Häkchen wieder gesetzt und dies für alle Ordner und Dateien im betroffenen Ordner übernommen und siehe da: Windows Search funktioniert tadellos.

Problem gelöst!


Aktuelles finden Sie stets auch auf der Website, oder auf Twitter.  

Experten machen den Unterschied: Lesen Sie, weshalb die Zusammenarbeit mit einem Microsoft Partner Silver Small Business und und Mitgliedsunternehmen der MSPAlliance die Wettbewerbsfähigkeit Ihres Unternehmens erhöht.

Sollten Sie aktive Unterstützung benötigen, können Sie sich jederzeit an uns wenden und nach unseren Managed Services, oder unseren Microsoft Office 365 Diensten für kleine und mittelständische Unternehmen in der Region Hamburg fragen.

Unsere Aufgabe ist es, Ihnen bei der Verwaltung Ihrer Netzwerke zu helfen, damit Sie sich um Ihr Geschäft kümmern können.

Lassen Sie uns Ihnen helfen, die Methoden und Richtlinien zu entwerfen, die Ihr Unternehmen noch erfolgreicher machen.

Unser Ziel: “Enterprise Solutions and Quality for Small Business”

Unsere fünf Kerndienste: Managed Workstations – Managed Email – Managed Cloud – Managed Continuity – Managed Security

24. Oktober 2012 Posted by | NIERO@net e.K. ServiceDesk | , , , , , , , , | Kommentare deaktiviert für 2 Supportfälle–2 Lösungen (Windows Search & Business Contact Manager 2010)

Wussten Sie schon……. Windows 7 Benutzerordner verschieben

Ich bin durch Zufall auf XING auf folgende Frage gestoßen:

bei mir ist ein Gau eingetreten. Auf meiner Systempartion war nicht mehr genug Speicherplatz. Daher wollte ich die User Daten und die System Daten trennen.
Ich habe diese Änderung nach einem Artikel aus der Zeitschrift Com! 07/2012 S. 20 durchgeführt. Beim zuweisen des Befehls "mklink" habe ich einen Fehler gemacht. Beim Rückgängig machen mit "rmdir" habe ich mir die User Daten auf der neuen Partion gelöscht.
Im Abgesicherten Modus kann ich Windows starten. Allerdings funktioniert nichts korrekt. Mit der Software "RECUVA" kann ich die Daten auf der Platte sehen. Die Widerhestellung funktioniert allerdings nicht.
So habe ich die Profile verschoben:
Start von der Installations DVD
robocopy SYSTEM:\useres DATEN:\users /mir /sec /xj
rd SYSTEM:\users /s /p
mklink SYSTEM:\users DATEN\users (hier ist mein Fehler: Ohne Parameter /j)
Ohne den Parameter funktionierte der Link nicht. Ein zweites Mal kann man den Befehl nicht ausführen. Im Internet fand ich einen Hinweis, dass mit "rmdir DATEN:/users /s /p" die Verknüpfung gelöscht werden kann. Damit waren allerdings die Daten gelöscht.
Wie sollte ich jetzt vorgehen? Die Daten scheinen sich ja noch retten zu lassen. Im Abgesicherten Modus gibt es ein "Windows reparieren" Eintrag. Sollte ich diesen benutzen oder einen anderen Weg gehen?

Abgesehen davon, dass das in verwalteten Umgebungen so nicht vorkommt und das man nicht irgendwelche Zeitschriften bemüht, sondern für geschäftliche Devices jemanden fragt, der sich damit auskennt, gibt es unter Windows 7 einen einfachen Weg auf der GUI die Benutzerdaten auf eine andere Partition zu verschieben.

Dieser Weg gilt für (fast) alle vom System während der Profilgenerierung erstellten Benutzerordner unter %USERPROFILE%, inkl. „Desktop“. Alles Weitere wird von Microsoft nach meinem Wissensstand nicht unterstützt. Es sei denn man befindet sich in Umgebungen mit Roaming Profiles.

1. Rechtsklick auf den zu verschiebenden Ordner und Auswählen des Reiters „Pfad“:

clip_image001

2. Hier lässt sich nun das neue Ziel definieren und man wird gefragt, ob alle vorhandenen Daten zum neuen Ziel verschoben werden sollen:

clip_image002

Das Ganze kann im Bedarfsfalle rückgängig gemacht werden.

Wie immer sollte man vorher sowohl einen Wiederherstellungspunkt setzen, als auch vorher eine Systemabbild-Sicherung durchführen und einen Reparatur-Datenträger erstellen.

Wenn gleichzeitig die Computerschutz-Einstellungen so konfiguriert sind, dass vorhergehende Versionen gespeichert werden (Schattenkopien) ist man vor Unbill relativ sicher.

Links zum Thema:

http://windows.microsoft.com/de-DE/windows7/Redirect-a-folder-to-a-new-location

http://technet.microsoft.com/de-de/library/cc732275.aspx

http://windows.microsoft.com/de-DE/windows7/help/system-repair-recovery

1. August 2012 Posted by | NIERO@net e.K. ServiceDesk | , , , | Kommentare deaktiviert für Wussten Sie schon……. Windows 7 Benutzerordner verschieben