Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

Accueil - Le blog d'Alexandre GIRAUD MVP Forefront
Alexandre GIRAUD - MVP Forefront > Le blog d'Alexandre GIRAUD MVP Forefront
Articles et annonces sur toute la gamme Microsoft Forefront et autres outils de sécurité.
juil. 30
Utilisation des fonctions Reverse DNS pour créer des enregistrements PTR

Avec Microsoft Azure, on peut mettre en place des services (VM, Sites, …) et y associer une adresse IP publique. C’est assez pratique, si il est nécéssaire de mettre en place une publication. Il restait ensuite aux administrateurs de mettre en place les enregistrements DNS auprès de son fournisseur DNS (OVH, GoDaddy, …) si l’on souhaite y accéder avec un nom de domaine de l’entreprise au lieu de cloudapp.net.

Mais il n’était pas possible jusqu’à présent de créer les enregistrements inverses (PTR). C’est à dire, que depuis l’adresse IP, on puisse obtenir le nom DNS complet. C’est d’ailleurs utilisé par certains systèmes de protections et sécurité (antispams, …). Mais voilà, vous l’avez peut-être déjà pensé, alors Microsoft l’a fait !

 

Alors prenons l’exemple d’un service que j’ai déjà dans Azure, une machine virtuelle avec une adresse IP publique. Afin d’y accéder j’utilise bien entendu un nom propre à mes besoins, et j’ai donc créer un entrée DNS chez mon fournisseur. Mon enregistrement sts dans la zone 3sr.fr correspond donc à l’adresse IP 137.116.213.217. Cependant, comme le démontre l’impression écran ci-dessous, impossible d’avoir le Reverse DNS !

image

 

Alors tout d’abord en prérequis pour cette manipulation, il faut une version récente du module Azure PowerShell soit la version 0.8.5 :

- Version Download : http://go.microsoft.com/fwlink/p/?LinkID=320376
- Version complète : http://az412849.vo.msecnd.net/downloads03/windowsazure-powershell.0.8.5.msi

Si vous ne savez pas quelle version vous avez, vous pouvez essayer cette commande : Get-Module -ListAvailable | Where-Object {$_.Name -eq 'Azure'} | Select Version

image

 

On se connecte à Azure (on sélectionne son abonnement si plusieurs), puis il suffit de configurer le service déjà existant avec « Set-AzureService » et l’argument « ReverseDnsFqdn ».

Attention, il faut un « . » à la fin. Donc dans mon cas je souhaite mettre en œuvre sts.3sr.fr donc il faudra mettre en variable sts.3sr.fr.

$Azure_Service_Name = 'AZURE3SR-WAP'
$Azure_Service_DNS = 'sts.3sr.fr.'
Set-AzureService –ServiceName $Azure_Service_Name –ReverseDnsFqdn $Azure_Service_DNS

clip_image002

 

Et là, … faut être patient ! Mais pas tant que ça, car dans mon cas j’ai attendu 5mn seulement et j’ai relancé la même commande nslookup exécutée au début de l’article. J’ai déjà la mise à jour DNS de mon enregistrement PTR !

image

 

Plus d’infos sur le blog Microsoft Azure –> http://azure.microsoft.com/blog/2014/07/21/announcing-reverse-dns-for-azure-cloud-services/

juil. 30
Une mise à jour TMG, et oui ! Alors voilà le TMG SP2 Rollup 5

 

Il y en a qui pensent que Forefront TMG est mort … mais pourtant il y a bien encore des mises à jours que fournit l’éditeur. Nous avons ici droit au 5ème Rollup du Service Pack 2.

Pour le télécharger et l’article KB : http://support.microsoft.com/kb/2954173

Il contient 11 patchs :

2963805 : Account lockout alerts are not logged after you install Rollup 4 for TMG 2010 SP2
2963811 : The TMG Firewall service (wspsrv.exe) may crash when the DiffServ filter is enabled
2963823 : "1413 Invalid Index" after you enable cookie sharing across array members
2963834 : HTTPS traffic may not be inspected when a user accesses a site 
2967726 : New connections are not accepted on a specific web proxy or web listener in Threat Management Gateway 2010
2965004 : EnableSharedCookie option doesn't work if the Forefront TMG service runs under a specific account
2932469 : An incorrect value is used for IPsec Main Mode key lifetime in Threat Management Gateway 2010
2966284 : A zero value is always returned when an average counter of the "Forefront TMG Web Proxy" object is queried from the .NET Framework
2967763 : The "Const SE_VPS_VALUE = 2" setting does not work for users if the UPN is not associated with a real domain
2973749 : HTTP Connectivity verifiers return unexpected failures in TMG 2010
2700248 : Server that's running Forefront Threat Management Gateway 2010 stops accepting all new connections and becomes unresponsive

 

La version devient désormais en 7.0.9193.644 et le tableau a été mis à jour en conséquent : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=232

juil. 30
Renouvellement de certificat pour WAP, ADFS et même DirectAccess mais en PowerShell !

Il doit forcément vous arriver un jour de devoir renouveller vos certificats, car ils sont expirés, remplacés, révoqués .. ou encore parcequ’ils ont l’algorithme SHA-1 devenue déprécié et bientôt plus supportés (http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx).

Alors on va se simplifier la vie, et ce grâce à PowerShell afin de mettre à jour les certificats sur nos différents services web utilisant la technologie SSL. Dans cet article on va voir comment mettre à jour les certificats pour WAP (Web Application Proxy), ADFS 3.0 et même DirectAccess. Des services qui sont assez largement utilisés aujourd’hui.

Nous prenons dans ce cas précis, l’utilisation actuel d’un certificat Wildcard déjà installé sur les serveurs que nous allons supprimer, et réinstaller le nouveau puis configurer le service concerné afin d’utiliser immédiatement le nouveau. La méthode présentée ici, peut présenter une micro-coupure de service. Bien entendu, il est possible de faire différemment et de ne pas avoir cette coupure, mais cet article s’adresse à un public averti.

Alors en prérequis ici, nous avons juste déposer le certificat sur un partage réseau accessible par l’ensemble des serveurs ADFS, WAP et DirectAccess. Nous devrons initialiser ainsi quelques variables sur chaque serveur, afin de connaître l’emplacement du certificat (au format PFX), créer une variable de mot de passé sécurisée puis le nom DNS du CN.

$PFX_Path = '\\SERVEUR\Share\certificat.pfx'
$PFX_Password = Get-Credential -Credential 'PFX Password'
$DnsNameCN = '*.3sr.fr'

Ensuite se connecter sur chaque serveur ADFS :

###############################
# ADFS
#

# Suppression de l'ancien certificat et import du nouveau certificat
Get-ChildItem -Path cert:\LocalMachine\My -DnsName $DnsNameCN | Remove-Item
$NewCert = Import-PfxCertificate –FilePath $PFX_Path cert:\localMachine\my -Password $PFX_Password.Password

# Configure le nouveau certificat
Set-AdfsSslCertificate -Thumbprint $NewCert.Thumbprint

# Redemarre les services ADFS
Stop-Service drs
Restart-Service adfssrv
Start-Service drs

 

Et pour Web Application Proxy :

###############################
# WAP
#

# Suppression de l'ancien certificat et import du nouveau certificat
Get-ChildItem -Path cert:\LocalMachine\My -DnsName $DnsNameCN | Remove-Item
$NewCert = Import-PfxCertificate –FilePath $PFX_Path cert:\localMachine\my -Password $PFX_Password.Password

# Configure le nouveau certificat
Get-WebApplicationProxyApplication | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint $NewCert.Thumbprint

# Redemarre les services WAP
Restart-Service appproxysvc

 

Et enfin pour DirectAccess :

###############################
# DirectAccess
#

# Import du nouveau certificat
Get-ChildItem -Path cert:\LocalMachine\My -DnsName $DnsNameCN | Remove-Item
$NewCert = Import-PfxCertificate –FilePath $PFX_Path cert:\localMachine\my -Password $PFX_Password.Password

# Changement du certificat IP-HTTPS
$DAConfig = Get-DAServer
Set-DAServer -ConnectToAddress $DAConfig.ConnectToAddress

 

Je reviendrai très certainement avec d’autres mises à jours de certificats pour d’autres services, ou n’hésitez pas à me proposer des idées.

juin 25
Vous obtenez le message “Unable to configure the password reset service: Error getting authtoken from https://login.windows.net/3sr.fr/oauth2/token.” lorsque vous tentez d’appliquer la commande Enable-OnlinePasswordWriteBack

Suite à mon précédent billet, j’explique qu’il y a une mise à jour de DirSync qui permet de mettre en oeuvre la fonction de Password WriteBack. http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=307

Cependant, lorsque j’ai tenté de la mettre en oeuvre la première j’ai été confronté à un problème…. J’avais le message d’erreur : “Unable to configure the password reset service: Error getting authtoken from https://login.windows.net/3sr.fr/oauth2/token.

image_thumb[1]

Cela vient du fait que vous devez utiliser une identité Azure qui a pour pré-requis :

  • Global Administrator (bien entendu)
  • Ce compte n’est pas un compte fédéré ! (je vous conseille d’utiliser le compte natif en .onmicrosoft.com)

Un grand merci à Adam Steenwyk qui m’a aidé, et m’a permis de résoudre le problème. La documentation sur MSDN n’est pas encore à jour (à l’heure où j’écris) mais il m’a été confirmé que cela sera le cas très prochainement.

juin 25
Et encore une mise à jour de DirSync (1.06765.6 ) pour le Self-Reset Password via Azure

Nous parlions dans un précédent article l’arrivée d’une nouvelle mise à jour de DirSync (version 6385.0012 http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=299 ), qui apportaient comme amélioration la prise en charge de la synchronisations des certificats S/MIME pour le chiffrement des messages avec Office 365.

Et là, à nouveau une nouvelle version 6765.6, et bien entendu qui s’accompagne avec une mise à jour spécifique pour Azure ! Avec cette mise à jour, cela est un pré-requis pour mettre en œuvre la fonction de “Password Writeback” … kezako ?

Avec Azure AD Premium, il y a de nombreux fonctionnalités supplémentaires par rapport à la version gratuite. Parmi elles, il y a une fonction qui permet de fournir aux utilisateurs un portail d’enregistrements de questions/réponses personnelles afin de pouvoir réinitialiser aux-mêmes leurs mots de passe en cas de perte. Ceci est très pratique pour des identités purement Cloud, et ainsi s’affranchir de développer cette fonction. (voir mon précédent article pour l’accès à l’évaluation : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=306)

Mais à l’aide de la dernière mise à jour de DirSync, cela peut permettre également à des comptes Active Directory On-premises de bénéficier d’un accès au Self Reset Password (comme avec FIM SSPR) mais directement dans Azure. En fait, la fonction Password Writeback permettra de recevoir la notification de changement de mot de passe, et ainsi faire la réinitialisation du mot de passe à l’aide de DirSync.

Pour cela, il faudra donc télécharger et installer (ou mettre à jour) DirSync depuis ce lien : http://go.microsoft.com/fwlink/?LinkID=278924 et d’activer la nouvelle fonctionnalité à l’aide de la commande PowerShell (Enable-OnlinePasswordWriteBack). Microsoft documente cette configuration sur leur site : http://msdn.microsoft.com/en-us/library/azure/dn688249.aspx#BKMK_2

Voilà la commande PowerShell que je recommande :

$local_AD_Cred = Get-Credential -Message 'Compte de votre AD local'
$local_MAAD_Cred = Get-Credential -Message 'Compte de votre Azure AD'
Enable-OnlinePasswordWriteBack -LocalADCredential $local_AD_Cred -AzureADCredential $local_MAAD_Cred

image

juin 25
Microsoft Azure Active Directory Premium (MAAD) disponible en version d’évaluation !

image

Microsoft Azure Active Directory Premium est la version améliorée et payante de la version Azure AD classique. Elle ajoute de nombreuses fonctionnalités intéressantes, comme la gestion d’identités avancées, le branding, le reset password, …
Inutile de tout copier/coller, car tout est expliqué déjà sur MSDN : http://msdn.microsoft.com/en-us/library/azure/dn532272.aspx

Cependant pour accéder à cette fonctionnalité jusqu’à ce jour, il fallait avec un contrat Microsoft de type EA ou VL. Il était possible de faire l’acquisition de la fonction uniquement, ou d’utilise Entreprise Mobility Suite (qui inclut MAAD Premium).
Ces types de contrats ne sont pas accessibles à tout le monde, et surtout qu’il n’est pas possible donc d’évaluer MAAD Premium. Plus d’infos sur l’accès et la configuration de MAAD Premium, toujours sur MSDN : http://msdn.microsoft.com/en-us/library/azure/dn499825.aspx

Mais les choses changent, et en bien ! Depuis cette semaine, il est possible d’accéder à une version d’évaluation d’Azure AD Premium sans contrat de licences.
On le remarque tout simplement depuis l’onglet “Licences” dans l’annuaire Azure AD.

image

Une note explicative avant, vous indiquant surtout que cette évaluation est limitée à 90 jours. Ce qui sera suffisant normalement pour évaluer les fonctions (articles à venir …)
image

Un message vous indiquera que tout s’est bien déroulé … !
image

Et vous voilà avec 100 licences MAAD Premium !
image

\: En vous souhaitant une bonne évaluation :/

mai 09
Problème de configuration du client CRM pour Outlook

Microsoft Dynamics CRM est une application de gestion relation clients, accessible aussi bien en version Online et On-Premises. L’application est essentiellement accessible à travers une interface web directement depuis le navigateur, ou l’interface y est très riche. Mais il est également possible d’utiliser un client lourd, ce dernier s’intègre directement dans le client Microsoft Outlook. La version du client Outlook, permet notamment d’avoir une version cache “hors-ligne”. Ainsi en situation de déplacement sans connexion Internet, il est toujours possible d’utiliser Dynamics CRM. Une synchronisation s’effectuera lorsque la connexion Internet sera à nouveau disponible.

Pour permettre l’utilisation du client CRM pour Outlook, il faut quelques pré-requis. Par exemple, il faut que les services WIndows Identity Foundation soient installés. Ceci peut être fait à l’aide d’une simple commande PowerShell : Enable-WindowsOptionalFeature -Online -FeatureName "Windows-Identity-Foundation". Si vous utilisez Windows 8.1, il faut appliquer le Rollup 2 : http://support.microsoft.com/kb/2919956 (Build 06.00.0002.0046). Il est nécessaire également d’avoir le client Microsoft Online Sign-In Assistant. Et c’est bien ce dernier qui pose souvent problème, nous allons le voir à travers ce billet. Sinon, pour plus d’informations sur les prérequis, se rendre sur Technet http://technet.microsoft.com/en-us/library/hh699818(v=crm.6).aspx

Alors dans mon cas, je pars du principe ou je dispose de Microsoft CRM Dynamics CRM Online configuré avec des identités fédérés. Je suis avec un client Windows 8.1 x64 et Outlook 2013 x64. Après l’installation du client CRM, depuis le portail CRM Online, l’assistant me propose de configurer l’accès à CRM. Si on conserver l’option “CRM Online'” puis on clique sur le bouton “Tester la connexion”, l’assistant a bien trouvé mon identité SSO et les informations sur mon organisation.

image

Mais si je clique sur le bouton OK afin de valider, un message d’erreur survient …

image

On va donc examiner le fichier journal de l’assistant de configuration CRM pour Outlook :

16:17:12|   Info| === Début de la journalisation de l’Assistant de configuration Microsoft Dynamics CRM pour Outlook le 09/05/2014 à 16:17:12 ===
16:17:12|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ClientConfig.Initialize
16:17:12|   Info| Client Configuration Wizard Version      : 6.0.0002.0046
16:17:12|   Info| Client Configuration Wizard LanguageID   : 1036
16:17:12|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.Validator.IsOutlookInitialized
16:17:12|   Info| Query all rows in profile table
16:17:12|   Info| Outlook is  initialized
16:17:12|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.Validator.IsOutlookInitialized
16:17:12|   Info| Client Configuration Wizard Running Mode : Normal
16:17:13|   Info| Configuration file Type : OnPremise.
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ConfigInfo.ConfigInfo
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.OutlookCRMDatastoreInstaller.GetAllCRMOrgsInOutlookProfile
16:17:13|   Info| Logon mapi store
16:17:13|   Info| Logon admin service
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.OutlookCRMDatastoreInstaller.GetServiceIds
16:17:13|   Info| Query all rows in msg service table
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.OutlookCRMDatastoreInstaller.GetServiceIds
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ConfigInfo.CleanUpDatastoreIfNeeded
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ConfigInfo.CleanUpDatastoreIfNeeded
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ConfigInfo.ConfigInfo
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm.ServerForm
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.ServerForm
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm.SetUIData
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadAvailableUrls
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadAvailableUrls
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.SetUIData
16:17:18|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm._testConnectionButton_Click
16:17:18|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm.TestConnection
16:17:18|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.TestConnection
16:17:18|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm._testConnectionButton_Click
16:17:35|  Error| Error connecting to URL:
https://disco.crm.dynamics.com/XRMServices/2011/Discovery.svc Exception: System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied.

Server stack trace:
   à System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
   à System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
   à System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   à System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   à System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
   à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   à Microsoft.Xrm.Sdk.Discovery.IDiscoveryService.Execute(DiscoveryRequest request)
   à Microsoft.Xrm.Sdk.Client.DiscoveryServiceProxy.Execute(DiscoveryRequest request)
   à Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.DeploymentInfo.LoadOrganizations(AuthUIMode uiMode, Form parentWindow, Credential credentials)
   à Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.InternalLoadOrganizations(OrganizationDetailCollection orgs, AuthUIMode uiMode, Form parentWindow)
16:17:37|   Info| Fill organization comboBox with server information.
16:17:50|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm._okButton_Click
16:17:50|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm._okButton_Click
16:17:52|  Error| Exception : La référence d'objet n'est pas définie à une instance d'un objet.    à Microsoft.Crm.Passport.IdCrl.OnlineServicesFederationLogOnManager.GetBrowserClientAuthInfo(String redirectEndpoint, String partner, String policy, String& postData)
   à Microsoft.Crm.Outlook.ClientAuth.PassportAuthProvider`1.SignIn()
   à Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.SignIn(Uri endPoint, Credential credentials, AuthUIMode uiMode, IClientOrganizationContext context, Form parentWindow, Boolean retryOnError)
   à Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.GetAuthProvider(Uri endPoint, Credential credentials, AuthUIMode uiMode, Uri webEndPoint, IClientOrganizationContext context, Form parentWindow)
   à Microsoft.Crm.Application.Outlook.Config.ServerInfo.LoadUserId()
   à Microsoft.Crm.Application.Outlook.Config.ServerInfo.Initialize(Uri discoveryUri, OrganizationDetail selectedOrg, String displayName, Boolean isPrimary)
   à Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadDataToServerInfo()
   à Microsoft.Crm.Application.Outlook.Config.ServerForm.<InitializeBackgroundWorkers>b__2(Object sender, DoWorkEventArgs e)
   à System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

Nous avons donc ici 2 erreurs, rien que ça ! Si on se penche sur la première, le journal indique un accès refusé à l’adresse https://disco.crm.dynamics.com/XRMServices/2011/Discovery.svc. Etrange, car justement cette URL est dédiée à l’Amérique du Nord, et non l’Europe. Les programmes ont toujours du mal à traverser l’Atlantique, même avec le temps. Il est possible de connaître les URL de Discover CRM Online en fonction du type (MS Account, O365 Account) et de la localisation (EMEA, APAC, …) : http://msdn.microsoft.com/en-us/library/gg328127.aspx

Donc il aurait fallu que notre URL soit https://disco.crm4.dynamics.com/XRMServices/2011/Discovery.svc. Il est donc possible manuellement de faire la modification, en indiquant directement cette URL et se connecter.

image

Cependant, au sein d’une large organisation ceci n’est pas envisageable. Il est donc possible de déployer un fichier Default_Client_Config.xml et d’y indiquer les configurations par défaut. Le fichier de configuration pourra être ainsi déployé à l’aide d’outils comme SCCM (ou autre). Le fichier pourra contenir des informations comme ceci :

<Deployments>
    < Deployment>
           < DiscoveryUrl>https://disco.crm4.dynamics.com</DiscoveryUrl>
        < Organizations>
             <Organization IsPrimary='true'>3SR</Organization>
         </Organizations>
    </Deployment>
< /Deployments>

Plus d’infos sur les méthodes de déploiement de configuration du client CRM pour Outlook, sur MSDN http://msdn.microsoft.com/en-us/library/hh699665.aspx

A présent que l’adresse du serveur est corrigé, je n’arrive toujours pas à me connecter et la journal me présent désormais que la 2nde erreur telle indiquée dans le journal plus haut (Microsoft.Crm.Passport.IdCrl.OnlineServicesFederationLogOnManager.GetBrowserClientAuthInfo). Il semblerait donc que nous ayons un problème de gestion d’identité, étant donné la description de ce message. Nous avons vu en début de cet article, qu’en pré-requis il est nécessaire d’avoir l’assistant de connexion Microsoft Sign-In. Après vérification, je dispose déjà d’une version sur mon poste qui semble être à jour (7.250.4556.0) pourtant :

image

Je décide donc de désinstaller cette version, redémarre mon poste et tente à nouveau la configuration CRM. Cette fois-ci le message est explicit, et m’indique qu’il est nécessaire de télécharger une version de l’assistant de connexion Microsoft. il m’est d’ailleurs en plus suggéré deux liens :

Il suffit donc d’installer la version correspondante à son système; L’installation prends que quelques instants et un redémarrage est nécessaire.

image

Après installation, le niveau de version est inférieure à celle que je possédais auparavant, et me retrouve descendu en 7.250.4259.0

image

Je tente de configurer à nouveau mon client CRM, et là par magie tout fonctionne parfaitement. Le fichier de log ne montre ni erreurs, ni avertissements et tout se passe correctement !

image

Cela s’explique désormais, en trouvant cet article pour la version CRM 2011 http://support.microsoft.com/kb/2696603

Mais alors, comment en arriver là  ? Comme le poste sur lequel je me trouve est “presque frais”, j’ai donc installer l’assistant Sign-In Microsoft Online pour une raison bien précise, ou le composant était surement inclus dans une autre installation…. La réponse, comme j’administre du Microsoft Azure, du Lync, SharePoint Online, Office 365, … C’est avec les composants PowerShell d’administration, que j’ai du ajouter l’assistant de connexion Microsoft Online. Mais à présent que la version est descendue, puis-je encore faire de l’administration des services Microsoft Online ?

image

Oh, comme par hasard me voilà dans une situation où il ne m’est plus possible de me connecter aux services Microsoft Online avec PowerShell, mais je peux jouir des services de CRM Online depuis Outlook !!! Soit l’un, soit l’autre ?

Qu’il y a t’il comme version de l’assistant de connexion MS Online, connue en ligne ?

   

Si on fait la mise à jour en 7.250.43030, le client CRM continue de fonctionner mais il n’est pas possible de se connecter aux services en ligne Microsoft à l’aide de PowerShell.

Puis si on passe à la version bêta 7.250.4551, nous ne sommes plus capable de se connecter à CRM Online depuis le client Outlook, mais il est à présent possible de se connecter à Microsoft Online en PowerShell.

Et enfin, si on utilise la version 7.250.4556.0 (la plus récente à ma connaissance), il est toujours possible d’administrer Office 365 en PowerShell, mais la connexion à CRM Online ne fonctionne toujours pas !

Au final ? Nous avons donc bien un conflit important ici, car nous découvrons qu’il n’est pas possible d’avoir à la fois les prérequis pour le client Dynamics CRM Online et les prérequis pour l’administration des services Microsoft Online, un comble ! En fait pour mieux comprendre, le client CRM pour Outlook nécessite l’assistant en version 2.. Alors que pour PowerShell, il faut la version 7. Il y a une confusion pour l’utilisateur, car lorsque l’on télécharge le client 2.1, la Build est soit 7.250.4259.0 ou 7.250.43030. Comment par 7.x, c’est là que la confusion commence. C’est à partir de la version 7.250.4551 que nous avons l’assistant Microsoft Online Sign-In en version 7. Mais il n’est pas possible d’avoir à la fois la version 2.1 et 7.x sur un même poste; Alors à ce jour, et à ma connaissance, il n’est pas possible d’avoir le client CRM pour Outlook fonctionnel, tout en ayant accès aux services d’administration Microsoft Online via PowerShell. Ce sera donc soit l’un, soit l’autre; A vous de choisir !

avr. 12
FIM DirSync erreur, ne peut démarrer avec une erreur 2149781504

image

Depuis quelques temps, j’ai découvert que je ne disposais plus de synchronisation DirSync. Pourtant j’ai deux serveurs en haute-disponibilité, un en local et un autre sur Azure. Les deux se sont mis à ne plus fonctionner du jour au lendemain.

Si je regarde, les services “Windows Azure Active Directory Sync” et “Forefront Identity Manager Synchronization Service” sont arrêtés. Dans les journaux d’évènement, j’ai les erreurs ID 7001 et 7024 indiquant les problèmes de dépendances et que le service FIM Sync ne peut démarrer avec l’erreur 2149781504.

Log Name: System
Source: Service Control Manager
Date: 12/04/2014 13:09:42
Event ID: 7024
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DIRSYNC.3sr.local
Description:
The Forefront Identity Manager Synchronization Service service terminated with the following service-specific error:
%%2149781504

Log Name: System
Source: Service Control Manager
Date: 12/04/2014 13:05:01
Event ID: 7001
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DIRSYNC.3sr.local
Description:
The Windows Azure Active Directory Sync Service service depends on the Forefront Identity Manager Synchronization Service service which failed to start because of the following error:
The service has returned a service-specific error code.

Après suppression et réinstallation, mise à jour en dernière version, redémarrage, reconfiguration, réparation MSI, … Bref, aucune solution standard permet de relancer la synchronisation.

Si je regarde en détail, ce problème est apparu après un redémarrage du serveur. Ce redémarrage fait suite à une série de mises à jour Microsoft. Et parmi elles, une attire mon attention

image

La mise à jour GDR 3128 de SQL Server 2012 (KB 2793634) a été installé sur les deux serveurs qui présentent le problème. Alors, il suffit donc de désinstaller cette mise à jour puis on désinstalle DirSync également ensuite.

image

Après la désinstallation de la mise à jour SQL GDR 3128, puis des composants FIM DirSync faites un redémarrage du serveur. Après le redémarrage, tentez à nouveau l’installation de DirSync. Profitez ici de mettre à niveau DirSync si besoin, pour cela voir mon article précédent : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=299

Après l’installation de DirSync, n’oubliez pas de remettre à nouveau vos paramètres de filtrage (Filtrage, Containers, …) avant d’autoriser une première synchronisation. Puis vous vous apercevrez que tout est rentré dans l’ordre à nouveau !.

Cette mise à jour SQL pose donc bien un problème direct avec l’outil de synchronisation Azure Active Directory (DirSync), car le simple fait de la désinstaller permet à nouveau une synchronisation.

avr. 06
Recevoir une notification d’expiration de mot de passe grâce à PowerShell

image

Vous avez été peu être confronté un jour, à vous rendre compte que le mot de passe de votre compte (ou ceux de vos utilisateurs) est expiré. Ceci n'est pas un problème lorsque vous êtes au bureau avec une station membre du domaine, une notification vous sera proposée pour changer votre mot de passe directement depuis le Secure Logon Screen.

Mais imaginons que vous avez une infrastructure de VM sur Azure dédiée, avec une Active Directory uniquement en mode Cloud sans VPN site à site … ? Dans ce cas, il ne sera pas possible d'effectuer le changement de mot de passe depuis l'écran de login, d'autant que par défaut sur les serveurs la pré-authentification RDP (NLA) est activée. Alors, soit il faut désactiver le NLA. Mais dans ce cas, cela baisse le niveau de sécurité. Sinon, l'autre option consiste à avertir les utilisateurs que leurs mots de passe vont expirer. C'est cette option que je décris ici.

Pour cela, j'utilise PowerShell avec le script ci-dessous. Il suffit de configurer une tâche planifiée qui s'exécute quotidiennement. Il suffit de modifier les variables surlignés en jaune, et de le paramétrer sur l'un des serveurs disposants du module PowerShell Active Directory.

Contenu du script :

# Variables
$smtpServer = "smtp.domain.local" 
$from = alert-password@domain.local
$smtp_username = "DOMAIN\SmtpUser" 
$smtp_password = ConvertTo-SecureString "Mot2Pass" -AsPlainText -Force 
$smtp_credentials = New-Object System.Management.Automation.PSCredential ($smtp_username, $smtp_password)
$expireindays = 20 
$maxPasswordAge = 90 
$OUpath = "OU=HelpDeskUsers,OU=IT,DC=domain,DC=local" 
$today = (get-date)

 

# Recherche des utilisateurs activés qui ont un mot de passe qui expire
$users = Get-ADUser -SearchBase $OUpath -Properties GivenName,mail,PasswordLastSet -Filter {(PasswordNeverExpires -eq "False") -and (Enabled -eq "True")}
foreach ($user in $users)

{
    # Informations du compte utilisateur  
    $Name = $user.GivenName
    $emailaddress = $user.mail

    # Recherche en jours de la dernière modification du mot de passe
    $passwordSetDate = $user.PasswordLastSet
    $lastset_days = (New-TimeSpan -Start $today -End $passwordSetDate).Days

    # Expire dans x jours en comparaison avec la date de modification, et la durée max autorisée
    $expireson = $lastset_days + $maxPasswordAge 

    # Préparation du message email  
    $subject="IT Services : Attention, expiration du mot de passe dans $expireson jours"      
    $body ="
    Bonjour $name,
    <p> Votre mot de passe IT va &ecirctre expir&eacute dans $expireson jours.<br>
    Merci de vous connecter d'ici ce d&eacutelai et d'effectuer la modification du mot de passe.<br>

    Au del&agrave de ce d&eacutelai, vous ne pourrez plus vous connecter et vous devrez contacter votre administrateur.
    <p>Merci de votre compr&eacutehension<br> 
    </P>"  

    # Envoi du mail si l'expiration est < 20 jours  
    if ($expireson -lt $expireindays)
    {
        echo "Attention : Le compte de $Name expire bientôt ($expireson jours). Envoi d'un mail vers $emailaddress en cours"       
Send-Mailmessage -smtpServer $smtpServer -from $from -to $emailaddress -subject $subject -body $body -bodyasHTML -priority High -credential $smtp_credentials  
    }
else 
{
        echo "Information : Le compte de $Name expire dans $expireson jours. Aucun émail vers $emailaddress ne sera envoyé"
}
}

 

 

mars 23
Le 8 Avril 2014, la fin de Windows XP seulement ? et du support de Forefront UAG SP2 aussi !

image

En lisant Internet, on dirait que le 8 Avril ça va être la fin du monde presque, mais la fin de quoi en fait ? De Windows XP seulement ?

Fin de Windows XP, bien entendu !

Donc en effet, oui c’est surtout la fin de Windows XP en ce mardi 8 Avril 2014 que tout le monde retient, que certains se rappellent surement encore de Whistler ! C’était il y a 12 ans maintenant ! Il nous a bien rendu service, même si je me rappelle de la peur de tout le monde (entreprise et particuliers) avec le Service Pack 2, et que le système était un peu désaimé à cette période. Et aujourd’hui, certains ne souhaitent plus le quitter au point de devenir insociable en famille :

Le fait d’utiliser Windows XP en soi n’est pas interdit, mais l’arrêt des mises à jours de sécurité, de l’intérêt des développeurs, etc… fait que le système vous forcera tôt ou tard à devoir changer de système. Sinon, Microsoft fournit un outil de migration simplifiée et complet : http://windows.microsoft.com/fr-fr/windows7/products/features/windows-easy-transfer

Mais office 2003 également !

Et bien entendu, la version Office XP qui est arrivé presque en même temps que Windows XP? mais très vite remplacé par Office 2003 arrive lui aussi à terme. Il est donc conseillé là encore de prévoir de mettre à jour vos versions d’Office vers les versions 2010 voire 2013 directement.

Et concernant Forefront UAG 2010 ?

Le produit, bien qu’arrêté d’un point de vue développement, est toujours supporté à ce jour. Cependant, souvent les directions informatiques ne font pas attention au niveau de Service Pack minimum. Donc ce sera justement à partir du 8 Avril que le Service Pack 2 ne sera plus supporté ! Il faut donc prévoir, pour les retardataires, une mise à jour vers le Service Pack 3 Rollup 1, voire directement le Service Pack 4.

Products Released

Lifecycle Start Date

Mainstream Support End Date

Extended Support End Date

Service Pack Support End Date

Forefront Unified Access Gateway 2010

mardi 26 janvier 2010

mardi 14 avril 2015

mardi 14 avril 2020

mardi 12 avril 2011

Forefront Unified Access Gateway 2010 Service Pack 1

vendredi 10 décembre 2010

Not Applicable

Not Applicable

mardi 8 octobre 2013

Forefront Unified Access Gateway 2010 Service Pack 2

lundi 6 août 2012

Not Applicable

Not Applicable

mardi 8 avril 2014

Forefront Unified Access Gateway 2010 Service Pack 3

lundi 18 février 2013

Not Applicable

Not Applicable

mardi 13 janvier 2015

Forefront Unified Access Gateway 2010 Service Pack 4

mercredi 20 novembre 2013

Review Note*

Review Note*

 

* Support ends 12 months after the next service pack releases or at the end of the product's support lifecycle, whichever comes first. For more information, please see the service pack policy at http://support.microsoft.com/lifecycle/#ServicePackSupport

Et si il y avait des bonnes nouvelles aussi prévue pour le 8 Avril 2014 ?

Mais bien sûr qu’il y a toujours des bonnes nouvelles, par exemple il est prévu que la mise à jour Windows 8.1 Update 1 soit publiquement disponible justement le 8 Avril 2014, coïncidence ?

image Encore une autre bonne nouvelle ? Oui mais celle-ci est plus personnelle, car c’est en ce prochain mardi 8 Avril 2014 que je fêterai mes 33 ans, où ce nombre d’années coïncidence avec le numéro de mon département qui plus est !

1 - 10Suivante
MVP Forefront

 ‭(Masqué)‬ Liens d'administration