Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

SCOM – Script – Comparaison Agents et Liste Machines

Le script ci-dessous propose de comparer un extract des agents scom avec une liste de machine, pour un suivi de déploiement par exemple.

Compare_SCOMAgent_ComputerList.ps1 (1,67 kb)

 

<pre class="wp-block-syntaxhighlighter-code">### COMPARE SCOM AGENTS AND COMPUTER LIST IN TXT FILE

#Parameters
Param(
[Parameter(Mandatory=$false)]
$MS="MyMS.MyDomain",
[Parameter(Mandatory=$false)]
$Cred = $(Get-Credential "MyDomain\Me"),
[Parameter(Mandatory=$false)]
$FilePath = "C:\ServerList.txt "
)


#Import du module SCOM
try
{
Import-Module -Name OperationsManager -ErrorAction stop
}
catch
{
write-host -ForegroundColor red "Erreur lors de l'import du module SCOM"
}

#Connection au management group $MGroup
New-SCOMManagementGroupConnection -ComputerName $MS -Credential $Cred


# Recuperation de la liste des agents (netbios name
$agents = Get-SCOMAgent | select computername -ExpandProperty computername


# Import du fichier $FilePath
try
{
$ComputerList = Get-Content -Path $FilePath
}
catch
{
write-host -ForegroundColor red "Error during import of `"$FilePath`""
}




# Machines dans Scom ET dans la liste
$Both = $(Compare-Object -ReferenceObject $agents -DifferenceObject $ComputerList -IncludeEqual -ExcludeDifferent).inputobject

# Machines uniquement dans SCOM
$InScom = $(Compare-Object -ReferenceObject $agents -DifferenceObject $ComputerList | Where-Object {$_.sideindicator -eq "<="}).inputobject

# Machines uniquement dans la liste
$InFile = $(Compare-Object -ReferenceObject $agents -DifferenceObject $ComputerList | Where-Object {$_.sideindicator -eq "=>"}).inputobject




write-host -B White -F Blue "`n $($both.Count) COMPUTERS THAT ARE IN SCOM AND IN FILE:"
$Both

write-host -B White -F Blue "`n $($InScom.Count) COMPUTERS THAT ARE ONLY IN SCOM:"
$InScom

write-host -B White -F Blue "`n $($InList.Count) COMPUTERS THAT ARE ONLY IN FILE:"
$InFile



</pre>

 

Office 365 : Voir qui a réservé la salle de réunion

Aujourd’hui lorsque l’on utilise Exchange Online et les boites aux lettre de salle, la configuration par défaut du calendrier de ces boites ne permet de voir que le statut de celle-ci soit « Libre ou Occupée » en revanche il n’est pas possible de voir qui a réservé la salle.

C’est parce que par défaut les droits sur le calendrier sont en « AvailabilityOnly« , comme le montre la capture ci dessous.

 

 

A l’aide de Powershell, il est possible de modifier les droits sur le calendrier pour afficher qui est la personne ayant fait la réservation, pour ce faire voici les cmdlets.

#Construction de la session Exchange Online
$cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $Cred -Authentication Basic -AllowRedirection

# Import de la session
Import-PSSession $Session

# Audit des droits
Get-MailboxFolderPermission -Identity Nom_de_la_Salle_de_réunion:\calendar

# Modification des droits
Set-MailboxFolderPermission -Identity Nom_de_la_Salle_de_réunion:\calendar -User default -AccessRights LimitedDetails

 

Maintenant il est possible de voir le statut de la salle de réunion ainsi que les personnes l’ayant réservé.

Azure Stack : Bug lors de la connexion PEP

Dans Azure Stack, l’établissement d’une connexion au PEP (Privileged EndPoint), appelé également VM ERC (Emergency Recovery Console), est nécessaire pour mener certaines opérations de test de l’environnement (Test-AzureStack préalable à une mise à jour) ou pour déployer certaines ressources (Resource Providers…).

La mise à jour 1910 d’Azure Stack introduit deux nouveaux cmdlet Powershell accessibles depuis le PEP : Get et Set-AzsDnsForwarder.

Malheureusement, il semble que ce module n’apprécie pas beaucoup d’être chargé depuis un ordinateur exécutant un système non-anglais puisque l’ouverture de la sessions PEP ne fonctionne plus non plus depuis cette mise à jour, avec un message d’erreur laissant entendre l’impossibilité d’ouvrir la version francaise du module AzureStack DNS :

clip_image002

Cannot find the Windows Powershell data file « Microsoft.AzureStack.DNS.psd1 » in directory « C:\Program Files\WindowsPowerShell\Modules\Microsoft.AzureStack.DNS\fr-FR », or in any parent culture directories

Les VM ERC sont assez lourdement verrouillées, et il est impossible d’aller corriger l’installation de ce module.

Il est par contre possible de forcer une Culture différente lors de l’ouverture de la Remote-PSSession à l’aide du paramètre SessionOption :

New-PSSession -ComputerName $IP -ConfigurationName PrivilegedEndpoint -Credential $AzureCredential -SessionOption (New-PSSessionOption -UICulture en-US)

Voilà qui devrait suffire à contourner le problème en attendant que Microsoft apporte une correction plus définitive !