Archive

Posts Tagged ‘Service Pack’

Comment prendre une copie de sécurité avant l’application d’un service pack


Tout d’abord, il est important de noter ce qui se passe lors de l’application d’un service pack. Lors de l’installation d’un service pack ou d’un cumulative update, il y aura une mise à jour des composantes applicatives localement sur chaque serveur et des mises à jour dans les banques de données.

Pour effectuer une copie de sécurité avant les changements, il faut donc s’assurer qu’il n’y a plus d’accès aux banques de données.  

Si vos serveurs sont virtuels, voici une petite procédure qui a été mis en place chez un client qui possède un environnement virtualisé sous VMware :

a)      Arrêt complet des serveurs de la ferme

b)      « Snapshot » Vmware de tous les serveurs de la ferme

c)       Copie de sécurité des banques de données Sharepoint

d)      Démarrage des serveurs de la ferme

Si vous n’avez pas la chance d’avoir un environnement virtualisé, vous pouvez effectuez les opérations suivantes afin de prendre une copie de sécurité intègre :

a)      Arrêt des services nécessaires sur chacun des serveurs de la ferme à l’aide du script ci-dessous :

iisreset /stop /noforce
net stop "Windows SharePoint Services Timer"
net stop "Windows SharePoint Services Administration"
net stop "Office SharePoint Server Search"
net stop "Windows SharePoint Services Search"
net stop "Windows SharePoint Services Tracing"

 

b)      Copie de sécurité  des lecteurs appropriés et du « System state »

c)       Copie de sécurité des banques de données Sharepoint

Avec ces copies de sécurité, vous pouvez procéder à l’application d’un service pack ou  d’un cumulative update l’esprit tranquille. En effet, si jamais l’installation ne se termine pas correctement et que vous n’êtes pas en mesure de corriger le problème, il vous sera facile d’effectuez un retour arrière.

Publicités
Catégories :Service Pack, Sharepoint, WSS Étiquettes : , ,

Attention au cumulative update d’août de WSS


Pour la troisième fois en quelques mois, un service pack ou un cumulative update de WSS/Sharepoint peut causer un problème.

Après le service pack 2 de Sharepoint qui plaçait le produit en version d’évaluation de 180 jours, après le problème avec les mappages de substitution du cumulative update d’avril, Stephen Gossner nous annonce aujourd’hui qu’il existe un pépin avec le cumulative update d’août de WSS.

En effet, cette mise à jour a introduit des changements aux procédures stockées et au schéma de la banque de données. À cause de certains de ces changements, il n’est plus possible d’attacher une banque de données de contenu qui ne provient pas d’une ferme Sharepoint qui n’est pas au niveau du cumulative update d’août.

Tous les détails sont disponibles dans le blog de Stephen.

Ceci étant dit, ce n’est pas une raison suffisante pour ne pas installer le cumulative update mais cela démontre qu’il est important d’avoir mis en place un bon plan de recouvrement au cas où les choses tournent mal.

Catégories :Service Pack, WSS Étiquettes : ,

Problème avec les mappages d’accès de substitution résolus


Le correctif fait partie du cumulative update d’août de WSS.

En effet, il y a quelques jours, Microsoft a publié un correctif KB973410 pour le problème décrit dans mes précédents billets du 13 juillet et du 25, le 26 et le 29 mai dernier.

Pour plus de détail sur le cumulative update d’août : KB973400

Attention, ce KB est pour WSS seulement. Ceux d’entre vous qui avez le problème avec MOSS devrait attendre le KB de MOSS pour installer les deux en même temps.

Catégories :Service Pack, Sharepoint, WSS Étiquettes : , , ,

MOSS et WSS Cumulative Update de Juin disponible


Comme à tous les 2 mois, Microsoft vient de publier le Cumulative Update de Juin pour MOSS et WSS.

MOSS:

972569 Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972569

970948 Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;970948

970947 Language specific
http://support.microsoft.com/default.aspx?scid=kb;EN-US;970947

972562 Language specific
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972562

972564 Forms Server Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972564

 

WSS:

971538 uber package
http://support.microsoft.com/default.aspx?scid=kb;EN-US;971538

970946 Global
L’article n’est pas encore disponible

Vous devez avoir le SP2 pour installer le cumulative update.

Catégories :Service Pack, Sharepoint, WSS Étiquettes : , ,

L’installation du SP2 écrase le fichier SPTHEMES.XML


Vous savez probablement déjà qu’il n’est pas supporté de modifier directement les fichiers de base du produit Sharepoint. Malheureusement, on doit contrevenir à cette règle si on désire ajouter un thème personnalisé.

 En effet, nous sommes obligés de modifier le fichier C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1036\SPTHEMES.XML. Pour le détail concernant la création d’un thème, vous pouvez consulter ces liens : http://sharepoint.developpez.com/faq/?page=V#34 ou http://www.asp-php.net/tutorial/asp.net/sharepoint-theme.php?page=1

 Ce qui devait arriver arriva. Nous avons installés le Service Pack 2 sur nos serveurs et notre thème personnalisé est disparu de la liste des thèmes disponibles. La solution est simple, il faut l’ajouter à nouveau dans le fichier SPTHEMES.XML sur chaque serveur de la ferme.

 Notons au passage que l’installation du Service Pack a changé la version contenu dans une ligne en commentaire du fichier SPTHEMES.XML :

 <!– _lcid= »1036″ _version= »12.0.6500″ _dal= »1″ –>

 Morale de cette histoire : Faites attention de bien tester suite à l’installation d’un Service Pack surtout si vous avez changer des fichiers de base de Sharepoint.

Catégories :Service Pack, Sharepoint, Thème, WSS Étiquettes : , ,

SyncUpgradeTimerJob: sleeping for 10 seconds


Lors de l’installation du service pack 2 de Sharepoint sur certains serveurs, l’installation semblait figer ou boucler pendant un très long moment. Un petit tour dans le log d’installation (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\logs\upgrade.log) et on découvre le message suivant à répétition depuis prêt de 20 minutes :

[SPManager] [DEBUG] [27/05/2009 16:51:01]: SyncUpgradeTimerJob: sleeping for 10 seconds
[SPManager] [DEBUG] [27/05/2009 16:51:11]: SyncUpgradeTimerJob: sleeping for 10 seconds
[SPManager] [DEBUG] [27/05/2009 16:51:21]: SyncUpgradeTimerJob: sleeping for 10 seconds
…..
[SPManager] [DEBUG] [27/05/2009 17:20:31]: SyncUpgradeTimerJob: sleeping for 10 seconds
[SPManager] [DEBUG] [27/05/2009 17:20:41]: SyncUpgradeTimerJob: sleeping for 10 seconds
[SPManager] [DEBUG] [27/05/2009 17:20:51]: SyncUpgradeTimerJob: sleeping for 10 seconds

Un petit tour sur le net et on trouve un blog http://community.zevenseas.com/Blogs/Robin/archive/2008/04/19/syncupgradetimerjob-sleeping-for-10-seconds.aspx qui parle du même symptôme que nous même si dans son cas c’était pour le Service Pack 1.

Nous avons tout de même appliqué la même recette soit de redémarrer le service SPTimer et SPAdmin et l’installation du service pack s’est terminée avec succès.

Catégories :Service Pack, Sharepoint Étiquettes : , ,

Problème avec les mappages d’accès de substition suite à l’application du SP2 et du CU Avril


Symptôme

Suite à l’application du Service Pack 2 de Sharepoint et du Cumulative Update d’avril, il se produit une erreur technique lors de la mise à jour ou la suppression d’un mappage d’accès de substitution.

Description détaillée du problème et procédure pour reproduire le problème

  • Créer un application Web, l’étendre sur une seconde zone et ajouter environ une dizaine de mappage d’accès de substitution (exemple : www.macompagnie.serveur1.mondomaine). Dans notre cas, avec 5 mappage seulement, on provoque le problème;
  • Installation du Service Pack 2 de Sharepoint;
  • Installation du Cumulative Update de Avril;
  • Tentative de mise à jour des mappages d’accès de substitution. Ça ne fonctionne plus.

Mise à jour : dans le billet suivant, je présente une manière simplifiée de reproduire le problème

Voici le message d’erreur que vous risquer d’obtenir :

Fin de l'analyse de fichier inattendue Name. Ligne 28, position 10. à System.Xml.XmlTextReaderImpl.Throw(Exception e)
à System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
à System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String arg)
à System.Xml.XmlTextReaderImpl.ParseQName(Boolean isQName, Int32 startOffset, Int32& colonPos)
à System.Xml.XmlTextReaderImpl.ParseElement()
à System.Xml.XmlTextReaderImpl.ParseElementContent()
à System.Xml.XmlTextReaderImpl.Read()
à System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace)
à System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
à System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
à System.Xml.XmlDocument.Load(XmlReader reader)
à System.Xml.XmlDocument.LoadXml(String xml)
à Microsoft.SharePoint.Administration.SPAlternateUrlCollection.HasMissingUrl(String xml)
à Microsoft.SharePoint.Administration.SPContentDatabase.UpdateAlternateAccessMapping(SPAlternateUrlCollection collection)
à Microsoft.SharePoint.Administration.SPAlternateUrlCollection.UpdateAlternateAccessMappingInContent()
à Microsoft.SharePoint.Administration.SPAlternateUrlCollection.Update()
à Microsoft.SharePoint.Administration.SPAlternateUrlCollection.Delete(Int32 index, Boolean update)
à Microsoft.SharePoint.Administration.SPAlternateUrlCollection.Delete(String incomingUrl, Boolean update, Boolean throwIfNotFound)
à Microsoft.SharePoint.ApplicationPages.EditIncomingUrlPage.BtnDelete_Click(Object sender, EventArgs e)
à System.Web.UI.WebControls.Button.OnClick(EventArgs e)
à System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
à System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
à System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
à System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
à System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

 Nous avons tenté de supprimer la zone, supprimer les mappages par STSADM, rien ni fait.

Un peu de réflexion du code pour en savoir un peu plus nous ammène jusqu’à une function qui reçoit en paramètre AlternateAccessMappingXml. 

Private Function GetDatabaseInformation(ByVal name As String) As String
Dim str As String = Nothing
Dim command As New SqlCommand("dbo.proc_GetDatabaseInformation")
command.CommandType = CommandType.StoredProcedure
command.Parameters.Add("@Name", SqlDbType.NVarChar, &H80).Value = name
Using reader As SqlDataReader = MyBase.SqlSession.ExecuteReader(command, CommandBehavior.CloseConnection)
If Not reader.Read Then
Return str
End If
If reader.IsDBNull(0) Then
Return str
End If
Return reader.GetString(0)
End Using
End Function

Nous sommes donc aller voir dans SQL server la StoreProcedure pour se rendre compte qu’elle ne gère que 1023 caractères ! La procédure retourne donc un document XML tronqué à 1023 caractères.

Informations supplémentaires

Pour l’instant, le problème semble se produire uniquement lors d’une mise à vers le Sp2 et/ou le cumulatif d’avril pour Microsoft Office Sharepoint 2007. J’ai fait quelques tests avec Windows Sharepoint Services qui possédait déjà le SP2 et ça semble bien fonctionner.

Contournement

Nous avons cru qu’en supprimant les mappages d’accès de substitution, qu’en effectuant la mise à jour de la ferme et qu’en recréant les mappages, nous aurions pu éviter le problème mais le problème nous rattrappe avec un message similaire.

Conclusion

Nous sommes à l’étape d’ouvrir un cas chez Microsoft. Plus de détails bientôt…

Mise à jour : Mon collègue Djamel Chagour a rédigé un article en anglais sur le même sujet.

Catégories :Service Pack, Sharepoint Étiquettes : , ,
%d blogueurs aiment cette page :