Exchange 2010, PublicFolder, geleiche Berechtigungen wie vorhandener User setzten

[seehas 11]

Hallo,

 

würde gerne per Script einem neuen User die gleichen PublicFolder-Berechtigungen wie die eines vorhandenen Users zuweisen. Natürlich könnte ich diese per

Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | where {($_.User -like "*%Username%*") }

auslesen und anschliessend per Hand (AddUsersToPFRecursive.ps1) die einzelnen Berechtigungen setzen. Aber schöner und komfortabler wäre ein Script bei welchem ich den vorhandenden und den neuen User als Parameter angeben kann. Das Script setzt dann die entsprechenden Berechtigungen beim neuen gleich wie beim vorhandenen User und gibt mir dann ein "kleines" txt-File als Logfile aus.

 

Leider sind meine Scripting Erfahrungen nicht gut genug und deshalb hoffe ich, dass mir einer von Euch weiterhelfen kann.

 

Gruss

seehas

[seehas 11]

Hallo,

 

Lösung gefunden.

 

Gruss

seehas

[tesso 375]

Würdest du uns die Lösung auch verraten? Falls jemand das gleiche Problem findet er so wenigstens auch eine Antwort.

[seehas 11]

Ja, klar. Das war auch meine Intension. Allerdings musste ich es noch ausführlich testen. Hier das .ps1 Script: 

####################################################################################################

# ADD A NEW USER, SAME PUBLIC FOLDER PERMISSIONS AS AN EXISTING USER

#

# $UserOld -> EXISTING USER

# 4UserNew -> NEW USER

#

# THIS CODE IS MADE AVAILABLE AS IS, WITHOUT WARRANTY OF ANY KIND. THE ENTIRE RISK

# OF THE USE OR THE RESULTS FROM THE USE OF THIS CODE REMAINS WITH THE USER.

####################################################################################################
Param(

 [Parameter(Mandatory = $true)]

 [string] $UserOld = "",

 [Parameter(Mandatory = $true)]

 [string] $UserNew = ""

)
####################################################################################################

# VALIDATE SCRIPT PARAMETERS

####################################################################################################
function ValidateParams

{

  $validInputs = $true

  $errorString =  ""
  if ($UserOld -eq "")

  {

    $validInputs = $false

    $errorString += $AddUserWithUserOnPFRecursive_LocalizedStrings.res_0001

  }
  if ($UserNew -eq "")

  {

    $validInputs = $false

    $errorString += $AddUserWithUserOnPFRecursive_LocalizedStrings.res_0002

  }
  if (!$validInputs)

  {

    Write-error "$errorString"

  }
  return $validInputs

}
####################################################################################################

# LOAD HASHTABLE OF LOCALIZED STRING

####################################################################################################
Import-LocalizedData -BindingVariable AddUserWithUserOnPFRecursive_LocalizedStrings -FileName AddUserWithUserOnPFRecursive.strings.psd1
####################################################################################################

# VALIDATE PARAMETERS

####################################################################################################
$ifValidParams = ValidateParams;
if (!$ifValidParams) { exit; }
else

{

 $pflist = "get-publicfolder -Recurse -resultsize unlimited"

}
$pfsToAdd = new-object System.Collections.ArrayList

invoke-expression $pflist | foreach {

 $OriginatingServer = $_.OriginatingServer

 [void]$pfsToAdd.Add($_.Identity)

}
$pfsToAdd | foreach {

 $permission = get-PublicFolderClientPermission -identity $_ -user $UserOld -erroraction Stop
 if ($permission -ne $null) {

  add-PublicFolderClientPermission -identity $_ -user $UserNew -AccessRights $permission.AccessRights

 }

}
####################################################################################################

# PUBLICFOLDER PERMISSIONS AS TXT-FILE FOR BOTH USER

####################################################################################################
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | where {($_.User -like "*$UserOld*") } | Out-File C:\$UserOld.txt

Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | where {($_.User -like "*$UserNew*") } | Out-File C:\$UserNew.txt
exit;

...und das .psd1 File:

ConvertFrom-StringData @'

###

res_0001 = \nMissing parameter: The -UserOld parameter is required. Use a valid user name or personnel number.

res_0002 = \nMissing parameter: The -UserNew parameter is required. Use a valid user name or personnel number

###

'@

 

[Daniel -MSFT- 129]

Ganz ehrlich? Das ist eine Lösung der Kategorie "Man nimmt eine tiefgefrorene Banane, um einen Nagel in die Wand zu schlagen". Dein Problem liegt ganz woanders:

 

Vergib die Berechtigungen NIE an Benutzer, sondern IMMER an Gruppen. Schachtel die Gruppen, so dass Berechtigung (Lesen, Schreiben, Ändern, Löschen, was Du halt unterscheiden willst) getrennt ist von Funktion (Verwaltung, Einkauf, Produktion, ...).

 

Dann musst Du nur noch die Anwender in Gruppen packen und hast damit auch eine Dokumentation, wer worauf zugreifen darf.

[seehas 11]

Ein Problem ist das eigentlich nicht und generell ist Deine ja auch Aussage richtig. ABER....

 

Es gibt immer Ausnahmen von der Regel und ich hatte gerade ein paar solcher Fälle, da hat es mich einfach genervt die Berechtigungen einzeln herauszusuchen und entsprechend neu zu setzten. Da habe ich für mich eine Lösung gesucht und wollte diese jetzt auch mit den Board-Mitgliedern teilen.

[Daniel -MSFT- 129]

Wie gesagt, nichts gegen Deine "Lösung" und das Teilen das Skripts. Finde ich Klasse. Ich habe nur noch keine begründete Ausnahme von der Regel gesehen ausser "Bequemlichkeit". Quick & Dirty fällt einem früher oder später auf die Füsse

[seehas 11]

Da hast Du recht. Trotzdem wird es eine Weile dauern bis eine vorhandenen und gewachsen Struktur umgestellt ist. Denn wie ich leidvoll erfahren musste arbeitet nicht jeder Admin mit Gruppen. Warum auch immer.

[Sunny61 806]

Da hast Du recht. Trotzdem wird es eine Weile dauern bis eine vorhandenen und gewachsen Struktur umgestellt ist.

Dann fang Du einfach an, ansonsten wird das nie etwas.

 

Denn wie ich leidvoll erfahren musste arbeitet nicht jeder Admin mit Gruppen. Warum auch immer.

 

Weil sie (er) es nicht wissen. Zeig es ihnen (ihm) wie einfach es ist, insbesonders wenn neue MA kommen. Der Aha Effekt kommt sicherlich recht schnell. ;)

[NorbertFe 2.034]

 

Denn wie ich leidvoll erfahren musste arbeitet nicht jeder Admin mit Gruppen. Warum auch immer.

Weil sie (er) es nicht wissen. Zeig es ihnen (ihm) wie einfach es ist, insbesonders wenn neue MA kommen. Der Aha Effekt kommt sicherlich recht schnell. ;)

 

Also mindestens einer hier im Thread arbeitet grad offensichtlich mit Nutzern die er irgenwie kopiert anstatt jetzt dort mit Gruppen anzufangen. Warum auch immer. :p

 

Bye

Norbert

[seehas 11]

Was soll ich sagen. Gerade hier angefangen und dies festgestellt. Da hier aber alles über eine zentrale Stelle entschieden werden muss, bin ich gerade dran dies entsprechend vorzubereiten um es dann vorzustellen. Einfach mal umstellen ist hier nicht. Aber Danke. Hab' Euch auch lieb...

:D  :jau: