Reprise du message précédent :
dans les deux cas ca me semble plus relever de la supervision
un outil de supervision peut lire des logs ou exécuter des scripts ou surveiller des services ou des URL etc. et remonter des alertes aux bonnes personnes.
Par contre je connais pas du tout PRTG

J'ai pas la main sur l'outil de supervision de l'infra.
Il est en amont.
L'ajout de nouvelles sondes (pour notre usage), coûte cher..
Et ensuite il faudra donner l'accès à PRTG à d'autres personnes.
 
Je sais pas trop en fait.

Cela implique aussi de bien normer tes logs.
Si tes X applications ont X manière de normer cela peut-être compliqué de faire tes tableaux auto de reporting dans Kibana.

Hm, supervision != analyse de log.
La supervision va vérifier que ton appli est up (répond un HTTP 200 sur /api/_health par ex) mais c'est tout.
Ce n'est pas son but de détecter une erreur applicative que tu auras dans tes logs (ça c'est pour ELK/filebeat/whatever...).

Toutes les applications ont la même "norme", puisque c'est une plateforme générique qui est réutilisée avec des paramétrages différents.

Par contre, les tâches planifiées et scripts sont pas normées, mais ça peut être fait après coup.

Tout à fait d'accord.
C'est pour ça que je ne suis pas chaud à utiliser PRTG pour ça et que je cherche un autre outil (et ELK/Filebeat me plaît pour cet usage)

je contre par ce que j'ai sous les yeux
scom :

surveille le nombre de fichiers dans un repertoire de traitement
- alerte si ca depasse => 1er critical
car le process de traitement est planté et bouffe la ram
- scom le detecte et tue le service => 2eme critical
- scom detecte que le process manque et le relance  => 3eme critical

la file est traitée, les 3 erreurs disparaissent sans avoir besoin de rien faire. toutes les 2-3h

ca revient a une citerne qui se remplit d'eau, deborde, reveille le chien qui dormait en dessous qui part en courant, sa laisse se tend d'un coup, ouvre le robinet de sortie et ramene le chien au pied de la citerne.

du grand art

Si ta besoin de suivre l'évolution des métriques de l'appli (tendances) c'est pas vraiment vraiment de la supervision (plus de la métrologie). Si ta besoin de déclenchement d'alertes pour réagir vite, ça oui c'est de la supervision.

Jette quand même un œil du côté TICK stack qui permet de tout faire (mais je suis moins calé sur le parsing de log avec TICK)

edit : pour résumer, en terme de facilité/prise en main ELK mieux pour les logs/trucs métier, TICK mieux pour la métrologie système/alertes/supervision.

Merci pour TICK, je regarde, ça a l'air bien effectivement.
 
Vous êtes vraiment calés quand même    
 
J'ai l'impression d'être une grosse quiche à côté  

Absolument pas, comme dit humanrage et comme j'ai dit plus haut une supervision peut lire des logs texte, des journaux d'événements, exécuter des scripts (et donc surveiller à peu près n'importe quoi), surveiller une page web (y compris son contenu, pas juste le code retour HTTP)...

Par contre effectivement si c'est pour faire de la supervision applicative alors que la supervision système est faite en externe, c'est pas forcément très pertinent de l'utiliser pour ca.

Je n'ai pas dit le contraire. La supervision n'est qu'un outil, il peut donc faire un peu tout et n'importe quoi (en fonction de ce que tu as acheté ). Si pour détecter que ton appli est OK t'as besoin de faire une requête SQL et de pousser un fichier sur ftp, c'est en effet ce que doit faire la supervision
 
Mais tu ne fais pas de l'analyse poussé de log dans une supervision (historique, recherche, détection de pattern, metrics, etc). Tu met en place un outil fait pour ça. Et si tu as un outil de supervision qui permet de faire tout ça, pas de souci, ça me va aussi

dans l'outil que je maitrise le mieux (SCOM) tu peux accéder à un historique des compteurs de perfs et de certains événements, mais c'est clairement pas du tout aussi souple qu'un agrégateur comme ELK ou splunk

 
Imagine moi étant seul "sachant" réseau, alternant et devant assumer les choix d'infras de la boite
 
Mais au moins c'est formateur et je vous remercie tous aussi pour vos conseils souvent plein de bon sens

D'où ma réponse pour du ON-line, les gros switchs on tendance à mettre longtemps à boot et ne supportent pas les coupures, même de 1s.

 
C'est chiônt d'avoir un onduleur qui coute 2x le switch

Faut prendre des switchs plus chers alors

Ou en prendre 2 pour la redondance  

Sinon pour le taff on a des routeurs avec un temps de cicatrisation de 30ms
 
Mais ils sont prévus pour fonctionner en anneau à la base

Putain le nouvel assistant de config de compte d'outlook 2016 fait vraiment très chier. Très très chier. T'es obligé de passer par ce putain d'assistant de merde de mes couilles, et si ta config de compte est un peu touffue, t'es baisé, t'as plus qu'a configurer d'abord un compte bidon mais fonctionnel pour avoir accès comme d'habitude.
 
Ça fait chier, putain de merde.

ils auraient dû laisser un accès à l'ancienne config des comptes sur outlook.

/importprf path:\<filename.prf> ?

Il y a pas une gpo/clé de registre qui règle ça ?

Chui chez les prolos moi, je suis en workgroup à déployer au cas par cas.

Uhhhhh.
 
Le jour où on atteint les dix machines je réclame un windows server avec AD kivabien.
 
Du coup tu clones toutes tes machines et tu te farcis les install à la mano ?

il est presta pour tout un tas de tpe/pme, c'est un peu différent de ton contexte

Ce qui explique du coup pourquoi le workgroup etc

Je ne clone pas, c'est plutôt sale (essaie d'utiliser le store windows après un clone session incluse, tu vas rire). vu que ça ne t’empêche pas de refaire tout le profil user à la mano.

Un pc de fabriquant je le reinstall avec le dernier support oem de windows (dans le cas de windows 10, la 1709)
Un pc assemblé j'install avec le dernier support oem

Comme ça pas de merde, unicité de tous les ids techniques, pas de bloatwares à la con, derniers patchs et drivers installés sans cumuls qui foutent la merde.

J'ai un pack d'install fait maison pour faciliter le déploiement des applis utiles à jour et proprement.

Et sur les postes, SSD le plus souvent possible (je mets du WD blue V2 en M.2 partout ou je peux à la place d'un dur même hybride).

sysprep generalize avant clonage ou wds

XaT

Certains gars du support ont perdus des journées entières avec du win10 et son store à la con. Avant d’aller lire les logs

Ca me fait toujours un peu halluciner les gens qui font du support mais qui testent un milliard de truc avant de penser à aller lire les logs, ou qui se retournent la tête sur des messages d'erreur un peu abscons pendant des heures (jours) au lieu de commencer par les googler

Laisse tomber la dreamteam.. on se marre tous les jours.  
 

De retour à mon extension d'AD
Je suis en train de faire le doc pour le projet.
 
D'après les conversations précédentes, pas besoin de modifier les OU.
Les deux DC existants sont dans le datacenter.
 
Il me faut donc un serveur local ici.
Est-ce qu'il y a besoin d'une grosse machine ou pas la peine ?
Je me tâte à prendre un petit ESx, mais j'ai pas encore identifié tous les besoins en interne. En plus on va déménager dans moins d'un an, donc ça fait chier.
 
Ensuite, faut que j'achète un parefeu watchguard et que je monte le tunnel vpn avec (c'est aussi du watchguard en sb).
J'en profiterai pour changer de classe d'ip pour notre réseau local, on est en class C, j'ai plus d'ip dispo à moins de changer de subnet.
Mais je ressens pas le besoin de faire une séparation "forte" en subnet en interne.
 
Je dois faire attention à quoi d'autre lors du montage du DC en local ?
Les postes locaux sont tous sous W10, et en workgroup.
Il faudra donc les rattacher au domaine, probablement une migration à faire car leur compte actuel ne correspond pas à celui du domaine en SB.
 
Je pensais pas faire de backup particulier, car je suis capable de remonter le DC à part de ceux en Salle Blanche (à moins que vous me disez le contraire).
 
Merci pour votre aide

Vu la taille de ton parc, t'as clairement pas besoin d'une grosse machine non.
A la grosse louche tu peux sur deux coeurs CPU (ca va se tourner les pouces de toute facon), pour la RAM tu comptes recommandation OS + antivirus/supervision/backup... + la taille de ta base AD + un peu de marge pour que tu puisses te logger sur la machine sans que ca swape et roule
 
Niveau subnets locaux tu connais mieux ton infra que nous et les besoins potentiels de séparer les réseaux/créer des vlan...
 
Tes W10, c'est bien des W10 pro/entreprise?
 
Pas sur d'avoir compris la remarque sur le backup
 
de rien bisou

À partir de combien de poste sur le réseau vous mettez un serveur wsus ?

La question à du être posée plein de fois je pense

ça dépend de la BP dispo et de la politique. Si ta 100meg et que ya 0 politique => Yolo windows Update.

Si tu veux pouvoir gérer l'approbation/refus de certaines MaJ, avoir un PC de test pour tester les MaJ tu n'as pas le choix => WSUS.

Ok pour la machine.
Pour les subnets, y a des bonnes pratiques spécifiques ?
Je fais un VLAN 1 pour les équipements, et le reste ce sont les lusers.
Pour même pas 100 personnes, sans serveur "locaux" à part l'AD et éventuellement un serveur de fichier, je vois pas trop l'intérêt de cloisonner ?
Pour le backup, c'est si mon DC local tombe (serveur en rade, ou corrompu) et qu'il faille remonter l'image.
 
Oui, ce sont tous des version Pro & entreprise.

 
Je dirai que ça dépend de ta connexion Internet et du nombre de postes. En formation on avait 100 postes et 5 méga, je te laisse imaginer le mode yolo Windows Update

En terme d'auditabilité c'est quand même mieux d'avoir le contrôle des updates.
 
En audit, j'ai cette question qui revient souvent (en anglais dans le doc) : comment contrôler vous les changements de votre SI ? Quelles sont les différentes étapes ?
 
Et une des bonnes réponses c'est clairement d'avoir :
1) un serveur centralisé (style WSUS) pour la bonne et simple raison que vous pouvez savoir à l'avance ce que vous allez avoir à déployer, et ce que vous voulez déployer (vous n'avez pas ce contrôle sur vous laissez faire Windows Update)
2) Vous pouvez effectivement déployer sur des machines de tests et ensuite déployer en plus grande pompe dans le parc.

Bah tu peux vouloir isoler la téléphonie, ou des serveurs particulièrement sensibles, ou...
Mais vu ton infra c'est peut être pas très nécessaire en effet.
 
aAors attention, disponiblité et sauvegarde c'est pas pareil
Effectivement si ton DC local pète t'as qu'à le dégager et le recréer comme s'il n'avait jamais existé, c'est une bonne facon de faire
Par contre t'as intérêt à quand même avoir une sauvegarde de ton AD quelque part (pas forcément de ce DC), puisque si t'as une corruption qui se propage, ou une suppression accidentelle d'objets & co tu peux être bien embêté
Mais j'imagine que tu sauvegardes déjà ca dans ton datacenter en fait

 
Wé c'est quand même à toi de définir ce qu'est "un changement". Parceque si tu commences à mettre les windows updates dans le process de validation qualité/ISO, c'est fini, ta boite ne bouge plus.

Pas de téléphonie IP
Ça changera avec le déménagement.
 
Pas de serveur sensibles (à part l'AD) en local.
 

Ben pour la gestion des vulnérabilités, t'as pas trop le choix honnêtement..