Entre deux à cinq KB à mettre à jour en urgence avec 2 reboots obligatoires selon les machines.
============================
16/10/2019 : fin des MAJ des correctifs avec reboots.
Entre deux à cinq KB à mettre à jour en urgence avec 2 reboots obligatoires selon les machines.
============================
16/10/2019 : fin des MAJ des correctifs avec reboots.
Bonsoir,
A 16h51, nous avons été alerté par la non réponse de mySQL, après investigation il s’avérait que le service ne voulait plus se lancer sans raison aucune (pas de référence chez mySQL).
Après des heures infructueuses nous avons décidé de désinstaller mySQL et redéployer une version identique. En ce moment nous ré intégrons les derniers backups réalisés de vos bases en date du 11/09/2019.
Hébergement vôtre.
PS : 21h tout est remonté et fonctionnel. L’avantage avec RD serveur est que l’on peut tout remonter à l’identique en un temps record.
NB : alertes
1 2 3 4 5 6 7 8 |
2019-09-13 17:13:33 - Checking server status… 2019-09-13 17:13:33 - Trying to connect to MySQL… 2019-09-13 17:13:33 - Can't connect to MySQL server on '127.0.0.1' (10061) (2003) 2019-09-13 17:13:33 - Assuming server is not running 2019-09-13 17:13:33 - Checking server status… 2019-09-13 17:13:33 - Trying to connect to MySQL… 2019-09-13 17:13:33 - Can't connect to MySQL server on '127.0.0.1' (10061) (2003) 2019-09-13 17:13:33 - Assuming server is not running |
Quelques semaines après le souci est réapparu, aussi avec un peu d’erreurs cette fois ci j’ai pu corriger ces dernières en migrant en myISAM, c’est donc bien INNODB qui pose souci :
1 2 3 |
#default-storage-engine=INNODB default-storage-engine=MyISAM innodb=OFF |
Entre 2 et 3 MAJ importantes avec reboot obligatoire, à vos claviers pour les machines non infogérées 24/7 …
Bonjour,
Cette nuit du 07/08/2019, je lancerai toutes les MAJ des serveurs Windows qui ne sont pas en automatique.
Article BitDefender :
3 MAJ critiques avec reboot obligatoire, à vos serveurs …
A vos claviers, 2 MAJ importantes avec reboot nécessaire.
Lors de l’ajout d’une fonctionnalité, erreur WinRM qui apparaît avec soit disant un gestionnaire défectueux.
Cela n’en est rien, il suffit juste de vérifier que l’ip 127.0.0.1 est bien enregistrée dans netsh
1 |
netsh http show iplisten |
Vous devriez voir apparaître 127.00.1, si ce n’est pas le cas on va l’ajouter avec le code suivant :
1 |
http add iplisten 127.0.0.1 |
Puis on va relancer WinRM avec la commande suivante :
1 |
Restart-Service "WinRM" -Force -Verbose |
Et voilà, l’ajout de fonctionnalités fonctionne de nouveau.
Ha Microsoft quand tu nous tiens …
La gestion des sessions est assez aisée sous Active Directory, mais incomplet quand on ajoute Remote Application, après quelques heures de recherche je vous livre mes découvertes.
L’objectif : fermer complètement toutes les sessions de connexion au bureau à distance, en mode RDP ou Remote Application, et pas seulement déconnecter comme fait Windows désormais.
Sous Dos ou PowerShell exécuter : gpedit
Là nous allons devoir modifier deux droits, dans Configuration ordinateur et Configuration utilisateur.
Descendre l’arborescence jusque :
De là on va modifier deux lignes :
Répéter l’opération pour la configuration Utilisateur.
Lancer sous shell la commande : gpupdate afin de mettre à jour la stratégie.
C’est là où j’ai mis le plus de temps à comprendre pourquoi les sessions Remote Application ne se comportaient pas de la même façon que Active Directory.
Dans gestionnaire de serveur, cliquez sur l’icône Services Bureau à distance, puis sur Collections > QuickSession
Dans le menu déroulant Propriétés, cliquez sur Modifier les Propriétés et modifiez les champs comme indiqué dans l’image ci-dessous.
NB : j’ai fixé une limite de session active pour être certain qu’au bout de 12h (durée normale de travail ^^), la session soit bien fermée.
Il ne suffit pas d’activer un certificat, voici les actions à faire.
Rendez-vous dans l’administration de votre WordPress, section Réglages > Général. Il vous faudra modifier l’url en https.
Nous recommandons l’utilisation de ce script gratuit en license GPLv3 :
https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Sous Apache, la modification se fait dans le fichier de configuration via l’interface prévue à cet effet ou dans le fichier .htaccess (nous recommandons la première méthode).
Sous IIS, voici une méthode simplifié :
https://blog.rdmedias.com/iis-7-redirect-force-et-fixe-http-https
ou une méthode plus avancée :
https://aboutssl.org/iis-redirection-http-to-https/
http://robots-txt.com/ressources/robots-txt-https/
A priori pas besoin car désormais google n’implique pas de modification de HTTP > HTTPS :
https://support.google.com/webmasters/answer/83106?hl=fr
Bonjour, suite aux MAJ Windows de cette nuit une erreur système se produit au reboot : écran bleu avec win32k.sys défaillant, on y travaille …
Diagnostic : AVG Business Edition serait le souci, on attend un diag de l’éditeur vs 2008 R2.
============================
Réponse de AVG après deux mois de tests :
Merci d’avoir contacté AVG.
Après vérification des logs, il m’a été rapporté par mon niveau 2 que ce problème est dû au fait que vous utilisez un système d’opération (WinServer 2008 Standard) qui n’est plus supporté par la nouvelle version (AVG 18.8) de nos produits.
Nous vous prions de nous excuser pour la gène occasionnée et cette perte de temps. Cordialement,
Service Clientèle Technique
Donc cherchez plus ou cherchez ailleurs désormais 🙂