Reprise du message précédent :

 
J'aimerais pas être chez OVH ce matin  

 
Y'a rien a expliquer, suffit de chocoblaster.
 
C'est le plaisir d'un de mes helpdesk quand il voit un poste non-verrouillé, et je cautionne allégrement.

En plus quand ca va redémarrer y a moyen d'avoir un bon pic pendant 1-2h, bref bon courage à OVH  

Pain au chocolat et croissants pour tout le monde !!!

 
depuis un poste non-verrouillé, nouveau mail à l'équipe du gars (ou la boite si tu es une pute) "salut les gars, demain j'apporte des chocolatines pour tout le monde".
 
Et on est passé à 10% de verrouillage à plus de 95% en moins d'un an. Peut-être pas pour les bonnes raisons, mais les résultats sont là.  

1/2h t’es gentil encore.  
 
L’année dernière c’était juste une coupure réseau et ça avait mi une plombe à revenir fluide.  
 
La tout est éteint  

 
Je me dit que ici le message le plus clair serait le shutdown PC ... Mais je risque d'avoir des emmerdes avec ces pleureuse
 
 
 

oui et non
 
c'était en panne il y a quelques semaines aussi...

 
Je confirme que le chocoblast c’est la technique la plus efficace.

 
L’autre solution que le chocoblast, c’est  
 
- nouveau mail
 
To : patron
Subject : tu es un connard
Test : Bonjour patron, tu es un connard. Bisous.
 
Et tu n’envoies pas le mail, tu laisses la fenetre de redaction grande ouverte au premier plan et tu verrouilles la session, comme ça c’est le premier truc qu’il verra en deverrouillant.
 
Suées garanties, verouillages garantis jusqu’a la fin des temps.

Bof, ça te prive d'un ptidej quand même

UP du relou
 
 
C'est étrange pour OVH, les groupes électrogènes ne sont pas testés régulièrement ?
A notre DC, les groupes électrogènes sont "tièdes", comme ça, ça démarre très vite pour prendre le relais juste derrière les batteries.
Et y a des tests très fréquents.

Petite pensée pour mon ancien chef (qui m'avait un peu poussé vers la sortie): "Pas besoin de failover avec OVH"

 
Un groupe ca marchera toujours quand tu fais des test ...  

Et deux groupes ?

Ici on a un 2ème DC en secours.
Là je crois qu'on aurait déjà déclenché le PRA

Bon apparemment c'est reparti
 
J'attends avec impatience la vague de rageux "OVH c'est de la merde" "francais c'est de la merde" etc  

Les liens sont UP (donc les machines de GRA et RBX reviennent oklm). Ceux qui ont des machines à SBG ça doit pas être pareil

 
de mémoire pour office365 faut que tes gens se loguent avec leur adresse email
 
donc > UPN dans l'AD et on en parle plus
 
tu ajoutes le suffixe upn qui correspond au domaine email que tu vceux utiliser (et normalement au tenant créé dans azure)
du coup tes users peuvent se connecter sur leur PC comme avant, mais se loggueront dans Office 365 avec leur UPN

Il a été décidé la semaine dernière de ne pas monter de DC chez OVH contrairement à ce qu'on avait envisagé de faire précedemment. C'était pas une mauvaise idée on dirait

 
Non.
Classic Shell si chez toi tu supportes pas le changement (perso je reviendrais pour rien au monde a l'ancien menu mais bon) pk pas
mais installer ca en entreprise c'est juste dégueulasse

Pour avoir utilisé leur private cloud, oui pour le prix c'est de la belle merde, incident majeur ou pas...

Merci du retour.
Il ne risque pas d'y avoir un conflit avec le service mail existant ? En gros, les users auront accès à 2 BAL (l'actuelle, et celle de O365).
Sauf que je souhaite à terme migrer les BALS du service actuel vers O365.
 
Et les users ne sont pas encore dans le domaine. On peut pas utiliser l'UPN également pour la connexion au domaine ?

ou bien comme je l'indiquais dans mon edit, t'as la possibilité d'utiliser un alternate id : https://docs.microsoft.com/en-us/wi [...] e-login-id

pour le coup du vpn pour discuter avec les controleurs de domaine dans le datacenter, ca me semble assez jouable

 
ca me semble méchamment pris a l'envers tout ca...
 
Tu veux faire de l'Office 365 sans de l'AD ? mais ton AD en .local te sert a quoi ? Tu peux créer des comptes locals dans Office365 donc non synchro a une AD local, mais est ce que tu pourras corriger ca ensuite je sais pas  
Quel interet d'avoir 2 boites mails ?  
pour moi ca va etre ingérable la migration, donc plutot tu actives pour tes users les services que tu veux dans OFfice365, sans le mail, et le jour ou tu es pret tu migres les boites actuelles dans 365
 
tu es accompagné sur ce dossier ?
Vu ce que tu dis, je ne saurai que trop te conseiller de prendre un prestataire qui connaisse bien sur le sujet en amont, histoire de pas faire n'importe quoi

Détaille un peu tes contraintes et le fonctionnement de ta messagerie actuelle et future, c'est pas hyper clair  
(hebergé comment/où, accédé comment...)

Ben si, on peut complétement utiliser l'upn pour se connecter au domaine, c'est même fait pour

Tu as envisagé de te faire accompagner par un consultant un peu calé sur les systèmes MS en général? Ca te permettrait de bien défricher tes problématiques sans te retrouver bloqué par une connerie que tu n'aurais pas anticipé par manque d'expérience, surtout vu le peu de temps dont tu disposes...

 
Office365 c'est pas juste un truc dans le cloud. Si tu veux faire ca bien y'a des adhérences un peu partout (genre que tes users ait pas a se loguer 10 fois), faut de l'AD, de l'ADFS, Azure AD Connect, faut voir si tu veux du SSO ou non, du mot de passe unique, etc
 
Vu la vitesse a laquelle MS developpe des produits dans Office365 et/ou Azure, tout en abandonnant le on premise   , je ne saurai que trop conseiller de faire ca bien, et de bien penser le truc des le début

Oula non.
Je dois très mal m'exprimer bien évidemment.
 
Il est hors de question de faire quoique ce soit sans l'AD.
Pour illustrer mes propos, prenons un exemple.
 
Notre domaine est cogip.local
Actuellement, cet AD est fait pour s'authentifier dans notre datacenter (qui héberge les deux contrôleurs de domaine) et sur les machines.
Je ne re-rentre pas dans les détails pour les OU, mais ce qu'il faut savoir, c'est qu'il y a une OU d'administration, dans lequel il y a différentes OU par DMZ (grossièrement ; PROD, TEST, DEV) et une OU pour le reste.
Dans cet grosse OU, la convention des comptes c'est "adm.leblanc_j" pour ceux qui ont accès à des machines, et les autres c'est "usr.leblanc_j".
On a certains outils tiers (Jira, Gitlab, etc) qui se basent sur ces OU pour l'authentification (c'est un détail).
 
Pour la partie mail, on passe par un prestataire (le même qui gère notre DC).  
Ils ont un serveur Exchange mutualisé, ce qui fait que pour paramétrer les comptes Exchange, on a des identifiants sous la forme "cogip-jleblanc@presta.com", mais l'adresse mail reste jleblanc@presta.com.
 
Dans l'infrastructure local (sur site), il n'y a aucun contrôleur de domaine. Donc tous les PC sont sous Workgroup.
Mes objectifs :
 
- Préparer l'AD pour intégrer les PC dans le domaine. D'après ce que j'ai compris, il faut séparer les OU d'administration VS les OU de desktop.  
- Mettre un serveur local pour monter un DC synchronisé avec ceux du datacenter
- En attendant, j'aimerai que les utilisateurs aient quand même accès à des outils de O365 (et que donc, ils utilisent le compte desktop de l'AD)
- Ensuite, j'aimerai migrer la messagerie du prestataire vers O365 ; de telle sorte qu'il n'y ait qu'un seul compte pour O365
- Enfin on passe dès que possible les poste des users dans le domaine, mais l'objectif c'est également d'avoir du SSO (une seule authentification sur le poste, ensuite on a accès à tous les outils O365)
 
Il y aura une migration à faire sur les comptes déjà présents dans les outils tiers, mais c'est encore une autre histoire.
 
 
 

Les étapes me paraissent pas dans le bon ordre

Tu devrais plutot te monter un nouvel AD tout beau et propre pour ton projet, avec O365, tes bécanes, les mails et tout dessus, et migrer les trois services qui se battent en duel dans ton datacenter dessus un peu plus tard.  
(ou pas du tout puisque il est completement décorrélé de tout ton AD actuel et n'a aucune incidence sur le reste).
 
Tu te bloques tout ton projet parceque tu veux réutiliser ton AD hébérgé qui ne sert en rien et n'a aucune incidence sur ton parc info.
- les ordis sont connectés dessus ? non.
- Les mails sont connectés dessus ? non.
 
Ben tu le laisse dans son coin ce machin, il sert à rien et ne bloque rien. Tu crées ton nouvel AD sur lequel tu mets tes utilisateurs, exchange, 365 et tout le reste .Et voila.
Tu décideras plus tard de ce que tu fais de l'autre.

Mais je le crée ou ce nouvel AD ?
Sur Azure & sur le DC local du site ?
Quel domaine ? cogip.com du coup ?

Dites chers collègues.
 
Question technico-légale :
 
Actuellement nous avons un nom de domaine fourni gracieusement par notre FAI.
 
On est passé chez OVH pour faire héberger notre site internet chez eux.
 
Jusque là tout me paraît cohérent sauf qu'il apparaît que notre nom de domaine est verrouillé chez le FAI et que je ne peux pas mettre notre site internet sous le nom de domaine fourni par notre FAI.
 
En demandant le déverrouillage du nom de domaine, le FAI me répond que le nom de domaine ne sera plus réutilisé.
 
Est ce qu'il sera dès lors possible de le réserver à nouveau ?
 
Merci

Hmmm le délire est le suivant :
 
Nous avons un nom de domaine disponible auprès de FAI (en l'occurrence l'Agrume pour ne pas le citer).
 
Nous avons externaliser l'hébergement de notre site Internet chez OVH et je souhaite utiliser le nom de domaine fourni par l'Agrume pour le site web en question.
 
Le souci que j'ai c'est que le nom de domaine est verrouillé et que l'adresse de contact n'est plus la bonne.
 
J'ai fait une demande de modif de contact auprès du registrar directement du coup afin de pouvoir récupérer le code déverrouillage.
 
Mais le délire de l'agrume sinon c'est de me dire que si on déverrouille, on perd la réservation du nom de domaine chez eux. D'où ma question de réutilisation.

 
Azure AD n'est pas un full AD. Il y a des fonctions pour joindre des postes Windows 10 sur un domaine Azure, mais tu peux pas mettre d'OS plus ancien
donc comme je doute que tu ais un parc full Windows 10, et comme y'a des limitations, je dirais qu'il te faut un DC local
 
pour le nom, suit les précos de MS, donc ni .local, ni domaine public directement, mais un sous domaine de ton domaine public, intra.cogip.com par exemple
 
dans tous les cas je le redis, prend un presta qui saura te conseiller au mieux
vu ce que tu expliques, y'a quasi tout a revoir, une excellente nouvelle d'un coté ca permet de partir sur du propre

 
Tu veux pas garder ton registrar actuel et faire pointer le DNS vers ton nouvel hébergement ?