Total noob here and i have a dilema... I need to apply Microsoft Calling Plan numbers to users based on region. Now what i want to do is import a .csv file of all the users and have powershell run a command that looks up available calling plan numbers in that region and then assign one to a user. then onto the next user, then the next and so on using the next available number each time.
As i have said i am not great with opwershell and i have thrown this togeth.
$Users = Import-CSV c:\filelocation\users.csv
$loc= (Get-CsOnlineLisLocation -City <city>)
$usernumber = (Get-CsPhoneNumberAssignment -isocountrycode GB -LocationId $loc.LocationId -NumberType CallingPlan -CapabilitiesContain UserAssignment -PstnAssignmentStatus Unassigned)
Foreach($user in $users)
{
Set-CsPhoneNumberAssignment -Identity $_.UPN -PhoneNumber $usernumber -PhoneNumberType CallingPlan
}
I have recently been scolded for using back ticks so that is something i need to ammend here but what i want it to do is lookup unassigned calling plan numbers for the $usernumber parameter and apply it in the set-CsPhoneNumberAssignment.
I have no idea how i loop it to apply the first available number and then move onto the next..
please help.
This script has not yet been run but i dont think it will work.
For matched loops like this you can use regular for($index = 0; $index -le $users.Length; $index++) {} syntax.
Then pass the index to both $Users and $UserNumber lists: $Users[$index].
Check for appropriate sizes first if necessary (especially if there are more users than there are available plans) to avoid ArrayOutOfBoundsExceptions.
Related
I'm trying to pull out a listing of all groups in our Azure Active Directory org along with all the associated members (be them users, groups, contacts, etc).
Since I was unable to locate a method to do this through the various Microsoft portals with a simple export button I began the process of obtaining access to the Microsoft Graph API/SDK via Powershell.
I'm by no means a PowerShell expert as it's not one of my go-to scripts; however, from what I can tell the ability to pull group info in this fashion is fairly limited.
The following is what I've been able to accomplish thus far:
Pull in a list of the groups using Get-MgGroup -All
Use Get-MgGroupMembers to pull back a list of Directory Objects.
This is where I get stuck. From what I've read it looks like a Directory Object by default only returns the ID and the Deleted Date. I'd like to get a display Name for these objects; I can obviously do this by running the appropriate 'Get' cmdlet for the type of directory object (i.e. Get-MgUser); From what I can tell the type of directory object can't be gleaned via PowerShell with out 'trial-and-error'... This seems highly inefficient to simply get a displayName.
Is there a more effective way to determine either the displayName of a Directory Object via a PowerShell cmdlet or at the very least a type so I can write a case statement to run the right cmdlet on the first try?
For the record this is going to be incorporated in to a Powershell Script, the current iteration of which looks like this and sorta works okay... assuming the Id passed in $member.Id belongs to a User type directory object.
Connect-MgGraph
$groups=Get-mgGroup -All
ForEach ($group in $groups){
$members = #{}
$members = Get-MgGroupMember -GroupId $group.Id -All
ForEach ($member in $members){
$user = Get-MgUser $member.Id
Write-Output $object.ODataType
Write-output $group.DisplayName "," $member.Id "," $user.UserType"," $user.DisplayName "," $user.UserPrincipalName "," $user.Mail >> C:scripts\Azure_Groups.txt
}
}
Would appreciate any direction/assistance on this. Thanks in advance!
Not sure why its not returning all the details on the PowerShell query:
This is working fine in MS Graph Explorer with the results showing all the details of the members:
For more details:https://learn.microsoft.com/en-us/graph/api/group-list-members?view=graph-rest-1.0&tabs=http#example-1-get-the-direct-membership-in-a-group
In preparation for a test, we need to load a Windows Server VM with up to 400,000 users and 100,000 groups, and various mappings between them.
A powershell script has been written to achieve this, running on a Server 2012 R2 VM (4 cores, 8GB RAM). However, at the rate the script is running, it's looking like it could take more than a month to complete.
We've tried the script using both the net command and the Add-AD commands to see if there's any speed increase. There doesn't seem to be. The script uses several For loops to iterate through creating users, creating groups, and adding certain users numbers to group numbers.
Command examples were:
#net users $userName mypassword /add
#New-ADUser -Name $userName -SamAccountName $userName -DisplayName $userName -AccountPassword mypassword -Enabled $true
and
net group $groupName $userName /add
#Add-ADGroupMember -Identity $groupName -Members $userName
Any suggestions on the fastest way to load an AD with a mass of new users/groups/mappings?
Thanks
The PowerShell cmdlets for AD are convenient, but they are not efficient.
Using ADSI directly will likely be faster because it gives you more control of what's going on. PowerShell has a shortcut notation of [ADSI]"LDAP://thepath" to create objects (they're technically DirectoryEntry object, but the examples here use the IADs methods).
There are instructions on creating users here, but I can summarize it:
[ADSI]$OU = "LDAP://OU=IT,OU=Departments,OU=Employees,DC=Globomantics,DC=Local"
$new = $OU.Create("user","CN=Ginger Snaps")
$new.put("samaccountname","gsnaps")
$new.setinfo()
#Account is created disabled, so we need to enable and set a password
#(the password can't be set until it's created)
$new.put("userAccountControl",544)
$new.setpassword("P#ssw0rd")
$new.setinfo()
You use $new.put() for whatever other attributes you want to set. You can also create groups this way too, just use "group" instead of "user" in the Create() method.
This is still going to take a while. It's the network connections that will hurt you the most. So you have to:
Get as physically close to a DC as you can (run it on a DC if you can), and
Keep the number of network requests down
If you do run this on a DC, then (if the domain has more than one DC) make sure to target the DC that you're on. You can do that by injecting the DC name into the LDAP:// strings, like this:
"LDAP://dc1.domain.com/OU=IT,OU=Departments,OU=Employees,DC=Globomantics,DC=Local"
Number 2 is limited by the fact that you have to do 2 requests per new user (one to create, one to set password). But you can do other things to keep the number down, like create all the users first and store the distinguishedName of each new user, which you can calculate yourself (rather than asking AD for it) because it's the CN=user that you pass to Create() plus the OU. So for the example above, the DN of the new user is:
CN=Ginger Snaps,OU=IT,OU=Departments,OU=Employees,DC=Globomantics,DC=Local
Once you have all those, you can create the groups and add all the members in one go. For example:
[ADSI]$OU = "LDAP://OU=IT,OU=Departments,OU=Employees,DC=Globomantics,DC=Local"
$new = $OU.Create("group","CN=group1")
$new.put("samaccountname","group1")
$members = #("CN=Ginger Snaps,OU=IT,OU=Departments,OU=Employees,DC=Globomantics,DC=Local", `
"CN=Another User,OU=IT,OU=Departments,OU=Employees,DC=Globomantics,DC=Local")
$new.put("member", $members)
$new.setinfo()
Where $members is your array of the distinguishedName for each member.
This way you have one network request that creates the whole group with the members already set, rather than one network request for each member.
I am looking to create a rule in Office 365 applied to all of the members in our org.
I would like this rule to append a warning on all incoming email from outside the organization with the same Display Names as our users.
When I attempt to apply it to all of the users in our org I get an error stating that the rule is too long.
In order to solve that I pulled a group, but I am still about 1000 characters over the limit.
I would like to make two variables, that each hold one half of the list, created by this command:
(Get-DistibutionGroupMember -Identity email#contoso.com -ResultSize Unlimited).DisplayName
I have attempted to modify the ResultSize parameter, but what I would need is result 1-100 and then 100-200 from the same list.
Another caveat to this problem is that the list cannot be static. It is something that the script will have to update every time it is run.
There is a sub-string command that you can use on a particular username that I have utilized when I made something for AD, but I am not aware of any way to break up a list like this.
If anyone has any other ways to solve this issue I would be more than open to any suggestion.
Thanks for taking the time to read this!
There are many ways of doing it. I found it very readable.
My favorite one is this one:
$ObjectList = 1..1000
$Step = 100
$counter = [pscustomobject] #{ Value = 0 }
$ObjectListSplitted = $ObjectList | Group-Object -Property { math]::Floor($counter.Value++ / $step) }
Then if you want to show the third subset just use this format :
$ObjectListSplitted[3].Group
Have a look to this solution already explained.
As a note other languages are capable of slicing an array of object with a start, stop and a step, have a look here if you're curious.
Background:
I'm trying to make a script that will see if a new users email ($email) is the same as one already existing (which would cause an error). I have a very remedial understanding of objects so this is what I have so far (yes it is ugly):
$email = "smithj#company.com"
$mailcheck = Get-ADUser -filter * -Properties * | ForEach-Object {$_.mail}
$mailcheck | ForEach-Object {if ($email -eq $_.mail){"$email = $($_.mail) - Matching email"}else{"$email = $($_.mail) - No duplicate email"}}
Problem 1:
The script doesn't match emails. When I have a matching email in AD it doesn't recognize it.
Problem 2: When executing just the 2nd line, indexing doesn't work properly. While it looks like a consecutive list of emails, if a user doesn't have an email at all (blank) really it could be something like this:
smithj#company.com
johnsonj#company.com
robertsr#company.com
doej#company.com
So $mailcheck[0] returns smithj#company.com while $mailcheck[1] returns blank despite the list actually looking like this:
smithj#company.com
johnsonj#company.com
robertsr#company.com
doej#company.com
Conclusion: I really just need problem 1 solved but problem 2 peaked my curiosity. Thanks.
The way you are doing it above is really inefficient. -Properties * will return every property on the user, some properties are expensive in terms of processing power to return. Only use the properties you need. The properties returned by default without specifying that parameters do not need to be specified with -Properties, only additional nondefault properties. -Filter * will also match on literally any value for any field, effectively returning every ADUser, further increasing the resources required for your script to execute as you will now have to process every user to find any accounts matching that email.
Now that that's out of the way, here is a more efficient method to implement what you're asking:
# Set the email address to search for
$emailAddress = 'box#domain.tld'
# Get all users where the email address matches what is set above
# Force it as an array so you can treat it like one even if only
# one or zero users are returned
$adUsers = #( Get-ADUser -Filter "EmailAddress -eq '${emailAddress}'" )
# Make sure no accounts were returned
# If there are, throw an error with the number of users and who they are
if( $adUsers ) {
throw "Found $($adUsers.Count) users matching EmailAddress ${emailAddress}: $($adUsers.SamAccountName -join ', ')"
}
By using the filter to only match the specific email address, Powershell does not need to collect every single AD user in the system, or iterate over all of them to find a specific email address. This will take a long time to check, especially in larger environments, whereas filtering the returned objects based on email address (or on any other property) results in a faster operation and less data to sift through.
You can then check whether $adUsers contains anything (an array count of anything but 0 evaluates to $True, you could also use if( $adUsers.Count -gt 0 ) as the condition), and if so, throw an error with more information as I do above.
Update for comment question:
To answer your other question in the comment, "I didn't know what object to compare $email to", EmailAddress and Mail both look to be valid properties, but I don't know the difference between them. In my environment, both Mail and EmailAddress are populated with my email address, but have always used EmailAddress and haven't run into issues using that. Maybe one is deprecated and the other is new or something, but I'm not really sure.
There is also yet another property called proxyAddresses as well, which preliminary research shows that both EmailAddress and Mail are related to it, but I don't know much about it. It's not populated on my ADUser objects, so I can't poke around with it.
So I have an interesting script I am trying to figure out, basically I need to change a custom attribute value to a new one. The problem is its for both users and computers and not specific to the groups. So for instance the value might be Billing1 for several users in an OU and this need to be Billing2. So I need to find any instance of the Value of Billing1 and change it to Billing2 not knowing the user or computer object. I can successfully change one at a time if I know who the user is by using Set-ADUser, Set-ADComputer and even with Set-AdObject but I need to figure out a Find and replace function.
I have searched for this and I have found examples of where I can use CSV for users and computers but again I don't know who has what since the value in the attribute can vary and also changes if a reorg happens.
got the correct script...
Get-ADComputer -Properties enterattributename -Filter {enterattributename -like "value to search" } |Set-ADComputer –replace #{ enterattributename =”value to change”}
this also can be applied to Get-ADUser and Get-ADObject