z.K. Microsoft hat heute das Update Rollup 9 für Dynamics CRM 4 veröffentlicht.
Weitere Informationen
- Knowledge Base (KB977650)
- Download Center
Tag Archive for 'microsoft'
Nachdem seit gestern Abend bereits Office 2010 als öffentliche Beta zum Download angeboten wird, steht nun auch der SharePoint Server 2010 zum Download bereit.
Leider ist die Seite im Moment nicht besonders gut zu erreichen.
Systemvorraussetzungen für die Installation:
Wer den Server installieren will, muss gewisse Mindestvoraussetzungen erfüllen: So sind ein 64-Bit-Prozessor, mindestens 4 GByte RAM sowie die 64-Bit-Version des Windows Server 2008 Standard mit dem zweiten Service Pack vonnöten.
Quelle: Golem.de
Hallo zusammen,
nachdem Microsoft die Beta Versionen von Office Professional Plus 2010 und SharePoint Server 2010 für Technet und MSDN Abonnenten am Montag freigegeben hat, steht zumindestens die Office 2010 Beta ab heute auch der Allgemeinheit zur Verfügung.
Nachdem man sich auf Microsoft’s Office 2010 Seite registriert hat, bekommt man einen MAK Key und die Möglichkeit Office 2010 Professional Plus (x86/x64) herunterzuladen.
Gruß,
Heyko
Nach dem Microsoft Workshop gestern, habe ich etwas mit Microsoft’s App-V herumexperimentiert.
Eine sehr gute, ausführliche Anleitung wie der App-V Client für den Standalone-Betrieb konfiguriert wird, gibt es hier.
Hallo zusammen,
zwischendurch mal wieder einen kleinen, wie ich finde, sehr nützlichen Tipp.
Und zwar kann man sich in einer Windows Domäne an jedem Arbeitsplatz mit dem Befehl
net user username /domain
eine detailierte Übersicht über das angegebene Benutzerkonto ausgeben lassen.
Dort kann man dann unter anderem das Datum der letzten Kennwortänderung, das dazugehörige Ablaufdatum und das Datum der letzten Anmeldung einsehen.
Nachdem Office 2007 so langsam auch bei uns im Unternehmen Fuß zu fassen beginnt, befasse ich mich nun auch etwas näher damit.
Mit Office 2007 entfällt, dass als Slipstream bekannte Verfahren, Updates in die Installationsmedien zu integrieren.
Es wurde durch ein neues, einfacheres Verfahren ersetzt. Auf den Office 2007 Installationsmedien gibt es ein Verzeichnis namens “Updates”. In dieses Verzeichnis können sowohl Servicepacks als auch Sicherheitsupdates für Office 2007 integriert werden, damit diese gleich bei der Installation mitinstalliert werden.
Um zum Beispiel den Servicepack 2 in die CD/DVD zu integrieren muss dieser vorher entpackt werden. Das erfolgt zum Beispiel (für SP2 in Deutsch) über den Befehl:
office2007sp2-kb953195-fullfile-de-de.exe /Extract:C:\Updates
Damit wird der Servicepack-Installer in das Verzeichnis C:\Updates entpackt. Die darin enthaltenen Dateien müssen jetzt in den Updates Ordner unterhalb der Installationcd kopiert werden.
Jetzt kann die Ordnerstruktur wie gewohnt z.B. auf CD/DVD gebrannt werden, oder als Netzwerkinstallationsquelle genutzt werden. Am Ende des Setups werden die Updates aus diesem Verzeichnis auf die Installation angewendet.
Heute Morgen sprach mich einer meiner Kollegen an, warum bestimmte Dokumente nicht in den Suchergebnissen unseres SharePoints auftauchen. Nach einigen Minuten bin ich dann auf diverse Warnungen (EventID 2436) im Eventlog gestossen.
Da ich vor kurzem unsere SharePoint Farm auf den neuesten Stand gebracht habe, lag die Vermutung nahe, das dabei etwas schief gegangen ist.
Nach einiger Recherche fand ich dann auch noch einen Leidensgenossen, durch den ich dann auch die Ursache und die Lösung gefunden habe. Bei den von mir installieren Updates, war unter anderem auch Service Pack 1 für das .NET 3.5 Framework dabei.
Hier mal die Warnung aus dem Windows Eventlog:
Ereignistyp: Warnung
Ereignisquelle: Office Server Search
Ereigniskategorie: Gatherer
Ereigniskennung: 2436
Datum: 03.06.2009
Zeit: 09:06:18
Benutzer: Nicht zutreffend
Computer: SharePoint01
Beschreibung:
Die Startadresse <http://moss2007> kann nicht gecrawlt werden.Kontext: Anwendung ‘SharedServices1′, Katalog ‘Portal_Content’
Details:
Zugriff verweigert. Überprüfen Sie, ob das Standardkonto für den Inhaltszugriff Zugriff auf dieses Repository hat, oder fügen Sie eine andernfalls eine Crawlregel zum Crawlen dieses Repositorys hinzu. Wenn das zu crawlende Repository ein SharePoint-Repository ist, überprüfen Sie, ob das verwendete Konto über die Berechtigung ‘Alles Lesen’ für die gecrawlte SharePoint-Webanwendung verfügt. (0×80041205)
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Zu diesem Problem gibt es auch einen Knowledgebase Artikel von Microsoft, in dem der Fehler folgendermaßen beschrieben wird:
Dieses Problem tritt auf, wenn die Website integrierte Authentifizierung verwendet und ihr Name der lokalen Loopbackadresse zugeordnet ist.
Abhilfe schaffte bei mir die Methode 2 “Hostnamen angeben”. Nach einem Neustart des ‘osearch’-Dienstes lief die Suche im Portal wieder fehlerfrei.
Update 11.06.2009
Hier noch ein paar andere Quellen zu dem Thema.
Wie so oft, vor einigen Tagen ging es bei einem Kollegen los und jetzt betrifft es von Tag zu Tag mehr.
Und zwar geht es um eine sporadisch auftretende Fehlermeldung des Internet Explorer sobald man versucht Google.de aufzurufen.
Hier mal auf einem Screenshot zu sehen.
Getestet habe ich bislang folgende Konstellationen:
- Internet Explorer 6.0.3790.1830 auf Windows Server 2003 R2
- Internet Explorer 7.0.5730.11 auf Windows Server 2003 SP2
- Internet Explorer 7.0.5730.13 auf Windows XP Pro SP3
Das Ganze in einer Windows 2003 Domäne hinter einem ISA Server 2006.
Wenn ich allerdings am ISA Server vorbei die Seite aufrufe, oder anstelle des IE <=7.0 einen anderen Browser verwende, ist der Fehler bislang noch nicht aufgetreten.
Im Netz findet man zu diesem Problem bereits diverse Seiten.
Ein nicht optimaler aber bislang funktionierender Workaround ist die betreffende Seite z.B. Google.de zu den “Eingeschränkten Websites” hinzuzufügen.
Über weitere Hinweise würde ich mich sehr freuen, da es doch ein sehr nerviges Phänomen ist.
Man kann in Outlook 2007 auch die Kalenderwoche im Kalender anzeigen lassen. Die Option befindet sich in
Extras > Optionen > Einstellungen > Kalenderoptionen
und heißt:
Wochennummern in der Monatsansicht und im Datumsnavigator anzeigen
Das Ergebnis sieht dann folgendermaßen aus:
Oder in der Monatsansicht:
Wir haben bereits seit einiger Zeit Schwierigkeiten damit, dass einige Clients keine Updates mehr von unserem WSUS (3.0) Server bekommen. Nachdem sich das Problem in den letzten Tagen häufte, bei immer mehr Clients aufgetreten ist und auch ein Update auf Service Pack 1 keine Abhilfe schaffte, habe ich zu dem Thema etwas recherchiert.
In Microsoft’s Knowledgebase gibt es zu dem Thema den Artikel 954960, genau dieses Problem beschreibt.
Das Problem äußert sich dadurch, dass auf den betreffenden Clients keinerlei Updates mehr ankommen und in der WindowsUpdate.log im Windows Verzeichnis (%windir%) der folgende Fehler auftaucht.
Date Time 788 ee4 PT +++++++++++ PT: Synchronizing server updates +++++++++++
Date Time 788 ee4 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://WSUS Server/ClientWebService/client.asmx
Date Time 788 ee4 PT WARNING: SyncUpdates failure, error = 0×8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200
Date Time 788 ee4 PT WARNING: SOAP Fault: 0×000190
Date Time 788 ee4 PT WARNING: faultstring:Fault occurred
Date Time 788 ee4 PT WARNING: ErrorCode:InternalServerError(5)
Date Time 788 ee4 PT WARNING: Message:(null)
Date Time 788 ee4 PT WARNING: Method:”http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates”
Date Time 788 ee4 PT WARNING: ID:c0a7445f-b989-43fa-ac20-11f8ca65fa8cQuelle: support.microsoft.com – KB954960
Laut Microsoft wird es durch ein überarbeitetes Update für Office 2003 SP1 verursacht, dessen Berechtigungen auf manchen WSUS Servern nicht richtig synchronisiert werden können.
Dieses Problem tritt auf, weil eine vor kurzem erfolgte Überarbeitung eines Updates von Microsoft Office 2003 Service Pack 1 (SP1) bewirkt, dass einige WSUS 3.0-Server das überarbeitete Update mit den Genehmigungen des Updates falsch synchronisieren. Wenn die betroffenen Clientcomputer mit einem solchen Server kommunizieren, kann der Webdienst die Genehmigungen nicht verarbeiten. Daher ist die Erkennung nicht erfolgreich.
Quelle: support.microsoft.com – KB954960
Gelöst werden kann das Problem durch ein Update des WSUS 3.0 SP1. Das Update ist im KB-Artikel verlinkt und für x86 und x64 erhältlich.
Ich habe es bei uns getestet. Gleich nachdem das Update auf unserem WSUS installiert worden ist, bekamen die Clients wieder Updates.
Warum das Problem bei uns erst jetzt und nur auf einigen Clients aufgetreten ist, fast ein halbes Jahr nach dem das Update durch Microsoft bereitgestellt wurde, ist mir ein Rätsel.
Recent Comments