#openblogPI
Ce post explique comment restaurer une base de donnée sous un différent nom/emplacement
Récupérer le nom logique de la base :
RESTORE FILELISTONLY FROM DISK='c:\backup.bak'Restaurer la base sous un autre nom logique / emplacement :
RESTORE DATABASE NouveauNomLogique FROM DISK='c:\backup.bak'
WITH
MOVE 'NomLogiqueduMDF' TO 'c:\NouveauNomLogiqueduMDF.mdf',
MOVE 'NomLogiqueduLDF' TO 'c:\NouveauNomLogiqueduLDF_log.ldf'Bonjour à tous,
Avec Windows 10, Microsoft a introduit un nouveau type de mises à jour appellées Servicing Stack Updates.
Ces mises à jour concernent uniquement le composant Servicing Stack de Windows.
Le Servicing Stack est responsable de deux choses principalement au sein de l’OS Windows :
Les mises à jour SSU ne sont pas incluses dans les mises à jour mensuelles cumulatives de Microsoft.
Elles constituent des mises à jour entièrement indépendantes et doivent donc être approuvées séparement dans WSUS afin que celles-ci puissent être déployées sur les postes concernés.
Elles seront cependant déployées automatiquement sur les postes ayant pour source Microsoft Update et non WSUS.
Attention, chaque SSU (tout comme les patchs cumulatifs mensuels), sont spécifiques à chaque version (Servicing Branch) de Windows 10 (1607, 1703, …).
La réponse est oui.
Les SSU sont un prérequis pour l’installation de certaines mises à jour mensuelles cumulatives.
Le cycle des SSU est différent de celui des mises à jour mensuelles cumulatives, donc il y a des mises à jour mensuelles cumulatives sans SSU correspondante. Si une SSU est un pré-requis à une MAJ mensuelle cumulative spécificfique, elle le sera également pour les MAJ mensuelles cumulatives suivantes.
Au contraire des autres mises à jour Microsoft, les SSU concernant un composant clé de Windows et uniquement lui seul (d’ou leur petite taille contrairement à celle des MAJ cumulatives mensuelles), ces mises à jour ne sont pas désinstallables.
Seule la restauration système peut être envisagée si vous devez vraiment faire marche arrière.
Bonjour à tous !
Aujourd’hui voici un billet pour les personnes rencontrant des problèmes de coupures intempestives sur des lecteurs réseau.
Des utilisateurs travaillant sur des lecteurs réseau vous rapportent des problèmes d’accès intempestifs à leurs fichiers, avec des coupures ou des lecteurs marqués comme déconnectés dans le poste de travail.
Ces coupures peuvent intervenir à n’importe quel moment de la journée et ne suivent pas des intervalles précis.
Cependant les serveurs hébergeant les partages concernés par les coupures semblent être toujours les mêmes, tout comme les postes de travail.
Vous pouvez remarquer que les plantages surviennent aussi lorsque les fichiers sont utilisés sur de longues periodes (applicatif sur un lecteur réseau par exemple).
Depuis Windows Server 2012 R2 ainsi que Windows 8, Microsoft a introduit une nouveauté dans le traitement des stratégies de groupe.
Le traitement des paramètres de préférences de stratégies de groupe (les fameuses Group Policy Preferences), et plus particulèrement celles concernant les lecteurs réseau se passe désormais en arrière-plan (background processing) et non plus uniquement à l’ouverture de la session d’un utilisateur (foreground processing).
En conséquence, quand vos lecteurs réseau sont mappés avec l’option Replace et non l’option Update, chaque rafraîchissement de la stratégie de groupe concernée entrainera une suppression du lecteur réseau, puis sa re-création provoquant ainsi une coupure temporaire.
C’est donc une nouvelle Best Practice à adopter, l’option Replace ne doit être utilisée que lorsque vous avez besoin d’écraser un paramètre pour le remplacer par un différent (je pense notemment à des mappages d’imprimantes lors d’un changement d’imprimante), l’option Update doit désormais être préférée pour tous les éléments ne devant pas être écrasés mais simplement mis à jour.
A bientôt,