Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, July 23, 2012 6:21 PM
I have a csv file that i am using to update some user attributes. The .csv file has the following attributes "Name,telephoneNumber,mobile,StreetAddress,City,Title"
I am new to powershell and was wondering what the easiest way to do this would be. Any help or ideas would be appreciated. This is to UPDATE existing users not create new ones. Thanks.
All replies (40)
Monday, July 23, 2012 7:15 PM ✅Answered | 2 votes
Hi,
You can use Powershell with Active Directory module (Require ADWS : http://technet.microsoft.com/en-us/library/dd391908%28v=ws.10%29.aspx).
Th Cmdlet you have to use is Set-ADUser : http://technet.microsoft.com/en-us/library/ee617215
I can't test right now but here is the way :
Import-Module ActiveDirectory
$USERS = Import-CSV c:\temp\users.csv
$USERS|Foreach{
Get-ADUser -filter {name -eq $_.name}|Set-ADUSer -TelephoneNumber $_.TelephoneNumber -MobilePhone $_.MobilePhone -StreetAddress $_.StreetAddress -City $_.City -Title $_.Title}
If you have the SAMAccountname in your CSV :
Import-Module ActiveDirectory
$USERS = Import-CSV c:\temp\users.csv
$USERS|Foreach{
Set-ADUSer -Identity $_.samaccountname -TelephoneNumber $_.TelephoneNumber -MobilePhone $_.MobilePhone -StreetAddress $_.StreetAddress -City $_.City -Title $_.Title}
Regards,
Thursday, August 14, 2014 1:41 AM | 1 vote
These type of questions is still actual today. And the answer is not entirely valid. That is in a sense that it does not work as there is an error - the first string (with filter by 'name') does not work at all, producing an error about none-existing parameter 'name' and the second string I managed to make work after figured out that its not just strange looking to me but indeed is missing a pipe sign after $.samaccountname. So I appreciate the information but not that much - time spent on figuring our why it does not work probably was more than I would spend just constructing the string myself from MS doc. Really, why provide sloppy information at all? If you don't care to make it accurate and usable maybe just dont do it? No offense, just curious.
Thursday, August 21, 2014 3:31 PM | 1 vote
Agreed. The first example doesn't even work so you can't exactly mark it as an answer.
Friday, November 18, 2016 8:01 PM
I am just in the same situation, but I don't understand how you suppose a pipe after $.samaccountname. It would look like this if I followed your suggestion:
Import-Module ActiveDirectory
$USERS = Import-CSV c:\temp\users.csv
$USERS|Foreach{
Set-ADUSer -Identity $_.samaccountname | -TelephoneNumber $_.TelephoneNumber -MobilePhone $_.MobilePhone -StreetAddress $_.StreetAddress -City $_.City -Title $_.Title}
I do not really get the point of the pipe, to be honest.
And my 2nd question is: won't this script UPDATE the samaccountname?
please help, I tried hours with a lot of scripts, nothing worked so far.
thx!
Friday, November 18, 2016 8:30 PM
You have a mistake in your copy of the solution. Please read the thread carefully and look at the help for the CmdLets before attempting to proceed.
\(ツ)_/
Friday, November 18, 2016 8:37 PM
vadim2 wrote:
"but indeed is missing a pipe sign after $.samaccountname"
Therefore I asked if he means it really the way I copied the solution. Because to me this seems not to be helpful. So my article is not a solution, it is a question. Please do also read carefully ;-)
indeed I have found an article about what I need, it's from MS, but seems wrong:
$P = Import-Csv processes.csv -Delimiter :
This does not work. But it works with -Delimiter ':'
Help from MS is useless, most articles have elementary typo errors.
Friday, November 18, 2016 8:44 PM
This is what you posted and it is not what was suggested in the answer. It cannot work and will give you some very clear errors. Copy the original answer as it is correct and works.
Note you mistake in the syntax of the command. See this for syntax help: https://technet.microsoft.com/en-us/library/ee617215.aspx
$USERS|Foreach{
Set-ADUSer -Identity $_.samaccountname | -TelephoneNumber $_.TelephoneNumber -MobilePhone $_.MobilePhone -StreetAddress $_.StreetAddress -City $_.City -Title $_.Title}
If you just want to register dissatisfaction or a complaint then post here: http://microsoft-reviews.measuredup.com/1/Reviews/Consumer-Complaint-1
\(ツ)_/
Friday, November 18, 2016 8:44 PM
ok, thx Richard. So set-aduser does - in this example - not write into the samaccountname field, but it reads it?
$USERS|Foreach{
Set-ADUSer -Identity $_.samaccountname
To filter on the base of the sam is clear to me, makes sense to me as I am just using it for my current filter.
But I don't understand why the above sample would read the identity... That does not mean that I don't believe it, ok? I just don't get it... :( !
UPDATE: okaaayyy, I was being completely confused about the identity... I thought "for each ad-user set the sam to the value of $._samaccountname". But of course this was bullshit. It sets the following parameters to the user's object with the given identity. Boah, much too late now...
Friday, November 18, 2016 8:45 PM
sorry jrv but I won't discuss with you any longer. You don't understand what I mean. Sorry...
Friday, November 18, 2016 8:49 PM
sorry jrv but I won't discuss with you any longer. You don't understand what I mean. Sorry...
You added a pipe for some unknown reason. Try starting by reviewing how to use PowerShell basics and how to use help so you can easily check you code for syntax issues before assuming it is a bug.
When first learning mistakes like yours are always due to a lack of understanding of the basics and not using help before giving up.
\(ツ)_/
Friday, November 18, 2016 9:07 PM
ok, your "unknown reason" is the result of either not reading my question carefully or I wrote it much to complicated. Maybe ;-). So, here again:
A user, vadim2, added on Thursday, August 14, 2014 1:41 AM the following suggestion. It is the third entry in this thread. I quote:
*These type of questions is still actual today. And the answer is not entirely valid. That is in a sense that it does not work as there is an error - the first string (with filter by 'name') does not work at all, producing an error about none-existing parameter 'name' and the second string I managed to make work after figured out that its not just strange looking to me but indeed is missing a pipe sign after $.samaccountname. So I appreciate the information but not that much - time spent on figuring our why it does not work probably was more than I would spend just constructing the string myself from MS doc. Really, why provide sloppy information at all? If you don't care to make it accurate and usable maybe just dont do it? No offense, just curious. *
MY question was, if HE is wright with the bold marked text.
Therefore (!) I copied the original text and inserted the pipe that he suggested. I already assumed that this would be useless, but I wanted to get sure if that is really that what he means, or if my english is that bad...!?
Friday, November 18, 2016 9:24 PM
That comment has nothing to do with the accepted answer. You need to read the thread more carefully and also pack of understanding of PowerShell basics will make it very hard for you to understand answers and when to ignore ambiguous comments by other untrained users.
No matter how you came to your issue reading the help and PowerShell documentation would have allowed you to understand how that comment could never be useful.
The issue is that you were wrong. The code in the marked answer is right (wright).
If you had tried to use the accepted answer you would have understood.
Richards comments clarified what you would have found in the help.
If you follow my suggestions you will have less issues with learning PowerShell.
\(ツ)_/
Friday, November 18, 2016 9:25 PM
This is what you posted and it is not what was suggested in the answer. It cannot work and will give you some very clear errors. Copy the original answer as it is correct and works.
I did it. Copied the original like you told me. Does not work.
Set-ADUser : Das Argument für den Parameter "Identity" kann nicht überprüft werden.
(argument for the parameter 'identity' cannot be checked)
Same result as 2 hours ago. But meanwhile I also made a script that works:
cls
Import-Module ActiveDirectory
$users = Import-Csv -Path D:\import\import.csv -delimiter ';'
foreach ($user in $users) {
Get-ADUser -Filter "sAMAccountName -eq '$($user.sAMAccountname)'" |
Set-ADUser -replace @{
"extensionAttribute1"=$user.extensionAttribute1;
...}
CAUTION: The last line ...} means that there are more entrys like in the line above (extensionattribute). DO NOT USE DOTs HERE IN YOUR SCRIPT!)
Friday, November 18, 2016 9:31 PM
Because the SamAccountName does not exist in the current domain.
The translation is not "checked" it is "found".
A simple test of your file:
$USERS = Import-CSV c:\temp\users.csv
$USERS | Foreach{
Get-ADUSer -Identity $_.samaccountname
}
Again this is basic PowerShell usage for validating code by using a simple test.
You will get errors on any samname that is not found in AD.
\(ツ)_/
Friday, November 18, 2016 9:40 PM
you quote a DIFFERENT code.
ok, my solution works, I know why!!
But I do not understand why you complain about my quotes, when you quote something completely different.
And NO - The translation is not "checked" it is "found" - is wrong in the way it is translated by MS.
German "überprüfen" means "to check".
English "found" (at this position in the english version of powershell) is in German "gefunden".
"To check" and "to find" is by far not the same!! And thats why german help of powershell is as wrong as the translation in german versions of help that comes from MS. And that also is why I stated that help from MS is often useless.
And this is where I say goodbye. I have yo finish my script now.
Friday, November 18, 2016 9:58 PM
The error means that the value passed is not a legitimate value for "Identity" no matter how you translate it.\
There is not point in this as you only care to prove something that has little to do with this thread. I see no point in this.
There are many ways to do this. You are free to pick you own method.
\(ツ)_/
Friday, November 18, 2016 10:54 PM
my script works, basically. If a field in the csv is empty, the scripts stops.
I found some script-ideas with if-loops, but all I found so far are used to find ad-objects with blank field, not blank csv-fields. How would you do it? For example not every user in the csv has a mobilephonenumber or ext.attr.1. Just enter a blank does not work, as the set-aduser cannot handle blanks...
thx!
Import-Module ActiveDirectory
$users = Import-Csv -Path D:\import\import-unicode.csv -delimiter ';'
foreach ($user in $users) {
Get-ADUser -Filter "sAMAccountName -eq '$($user.sAMAccountname)'" -Properties *|
Set-ADUser -replace @{
givenname=$user.givenname;
sn=$user.sn;
Description=$user.Description;
Department=$user.Department;
company=$user.company;
PostalCode=$user.PostalCode;
l=$user.l;
streetAddress=$user.streetAddress;
telephoneNumber=$user.telephoneNumber;
facsimileTelephoneNumber=$user.facsimileTelephoneNumber;
Mobile=$user.Mobile;
mail=$user.mail;
extensionattribute1=$user.extensionattribute1;
}
}
Friday, November 18, 2016 11:10 PM
Again- you are not reading the help. You are just copying things you have seen and applying them in odd ways to a lack of fundamental concepts.
What you are doing is not wrong but is ignores most of what PowerSHell provides.
This will work:
$users = Import-Csv -Path D:\import\import-unicode.csv -delimiter ';'
foreach ($user in $users){
if($u = Get-ADUser -Filter "sAMAccountName -eq '$($user.sAMAccountname)'"){
$u | Set-ADUser `
-Givenname = $user.givenname`
-Surname = $user.sn`
-Description = $user.Description`
-Department = $user.Department`
-company = $user.company`
-PostalCode = $user.PostalCode`
-City = $user.l`
-StreetAddress = $user.streetAddress`
-OfficePhone = $user.telephoneNumber`
-Fax = $user.facsimileTelephoneNumber`
-MobilePhone = $user.Mobile`
-EmailAddress = $user.mail`
-Replace @{ extensionattribute1 = $user.extensionattribute1 }
}else{
Write-Host "User not found $($user.sAMAccountname)"
}
}
This is more manageable:
$users = Import-Csv -Path D:\import\import-unicode.csv -delimiter ';'
foreach ($user in $users){
if($u = Get-ADUser -Filter "sAMAccountName -eq '$($user.sAMAccountname)'"){
$splat = @{
Givenname = $user.givenname
Surname = $user.sn
Description = $user.Description
Department = $user.Department
company = $user.company
PostalCode = $user.PostalCode
City = $user.l
StreetAddress = $user.streetAddress
OfficePhone = $user.telephoneNumber
Fax = $user.facsimileTelephoneNumber
MobilePhone = $user.Mobile
EmailAddress = $user.mail
Replace=@{ extensionattribute1 = $user.extensionattribute1 }
}
$u | Set-ADUser @splat
}else{
Write-Host "User not found $($user.sAMAccountname)"
}
}
\(ツ)_/
Friday, November 18, 2016 11:48 PM
as much as I appreciate your help, but... I am sorry to have to tell you that I got lots of errors (first script).
For each Name in the csv I get the following error:
Set-ADUser : Es wurde kein Positionsparameter gefunden, der das Argument "***" akzeptiert.
Bei Zeile:5 Zeichen:18
- $u | Set-ADUser <<<< `
+ CategoryInfo : InvalidArgument: (:) [Set-ADUser], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.ActiveDirectory.Management.Commands.SetADUser
and the 2ndd script gerenates not one black line. Only red:
Set-ADUser : replace
Bei Zeile:20 Zeichen:18
- $u | Set-ADUser <<<< @splat
+ CategoryInfo : InvalidOperation: (CN=**** ***...DC=bfinoe,DC=at:ADUser) [Set-ADUser], ADInvalidOperationException
+ FullyQualifiedErrorId : replace,Microsoft.ActiveDirectory.Management.Commands.SetADUser
Note: *** = I censored the names here in the posting
Saturday, November 19, 2016 12:03 AM
If the attribute dope's not exist you have to use "Add" and not "Replace".
I didn't post that as a complete solution or a teste solution as it cannot be tested by me in your environment. That is why you have to learn the basics of these technologies. YOU cannot rely on others to provide every piece of information.
I was providing simple examples of ways to use the CmdLets. It is up to you to learn how and why this works and to understand what teh erro messages mean.
I recommend just using a simple set of properties starting with one and adding one at a time until you understand how this works. I usually debug by commenting out the splat and adding properties back one at a time:
$splat = @{
Givenname = $user.givenname
<# Surname = $user.sn
Description = $user.Description
Department = $user.Department
company = $user.company
PostalCode = $user.PostalCode
City = $user.l
StreetAddress = $user.streetAddress
OfficePhone = $user.telephoneNumber
Fax = $user.facsimileTelephoneNumber
MobilePhone = $user.Mobile
EmailAddress = $user.mail
Replace=@{ extensionattribute1 = $user.extensionattribute1 }
#>
}
\(ツ)_/
Saturday, November 19, 2016 12:27 AM
my script updated like expected, existing values, but did not enter new ones. Seems reasonable.
So I start from the beginning with READING the HELP and test one part following the other:
get-aduser -identity testperson –properties * | set-aduser -city testcity
... doesn't work, error.
The object is there (can be found with get-aduser -identity testperson).
I finally give up because I'm proved not getting the simplest things running.
Will change 600 accounts by hand - I WOULD BE READY MEANWHILE... :-(
Thx again for your help.
bye
Saturday, November 19, 2016 12:40 AM
There is no reason for what you are saying. I suspect there are other issues with you installation.
I can use this on any system with no issue:
Get-Aduser testuser | Set-AdUser -City Atlanta
Get-Aduser jsmith -properties city | select city
and it works every time for ever account. If yours doesn't work then you likely need to look at language issues which I cannot resolve.
What valid parameters are available in German?
Help Set-Aduser -Parameter City
Remember that parameter names are location dependent. Again - this would be something learned from studying PowerShell basics.
YOU can do this just take the time to learn the basics. You would also do better posting in the German forum here. It would help to eliminate locale dependent issues.
\(ツ)_/
Saturday, November 19, 2016 1:29 AM
What I learned was that can I get the ad parameters from adsiedit. There it is city. Learned the wrong thing? It's directly from MS. So - WHAT should I learn? The wrong things? No, thanks. Just found out that (next issue!) Umlaute cannot be used in changings. And YES, my csv is already unicode. It just makes different special chars. It's all a bad joke with powershell... locale issues... in a scripting language. Linux users a laughing. Loud. It's now 2:30 A.M. Time to finally give up. Good night
Saturday, November 19, 2016 1:35 AM
In all languages special characters special characters have to be escaped.
It may be that you are using the wrong version of PowerShell for your locale which will cause many headaches.
There is no substitute for understanding the technology.
Support across locales and languages is excellent in the latest versions of PowerShell but it is still possible to install the wrong version. PS 2 has limited support for locale. Posting in the "de-GR" forum will help you resolve this.
\(ツ)_/
Saturday, November 19, 2016 9:47 AM
this powershell is a big sh!t - sorry MS, but a shell is something different! Have a look at shell-orientated operating systems like unix.
If I change the "l" attribute with powershell, the REAL attribute in adsiedit is changed for "userworkstations", which in ps should be logonworkstation.
If I change the "l" attribute with adsiedit, it changes the CITY attribute.
I can both prove in dsa.msc
So, here we come to the point where I have to say: Microsoft, you have lost your brain somewhere. How silly must one be to use different things/names/words for the same thing? Or why is the l-attribute in powershell something complete different?
They say it is "logonworkstation". I did not find anything that -l should be the same. Is it???
So I want to change the city attribute. Have a look in adsi - there the attribute is called l.
Do I use "l" in powershell, it changes the value for the adsi-attribute userworkstation.
If I now want to change the dsa "logon to" value , I have a look into adsi and find it -not under logon to-, but under "userworkstation". But I cannot use "userworkstation" in powershell, I have to find out that I have to use "logonworkstation". Which is not "l".
How many different words does microsoft need for the same thing? Is it really that impossible?
It's the same for nearly all other values, no common strategy. And that is typically a housemade MS b*lls**t.
@chars: when a user has an Umlaut, that is displayed the wrong way in dsa, I open the userobject with dsa, change something (another attribute, maybe "company", change it back to the original value), and the Umlaut is displayed correctly (I did not change the value with the Umlaut!!).
THIS IS MS. Completely brainless.
So, after this great damage to the whole AD I change everything with adsiedit. Who knows how other "tools" like ps and dsa can surprise me...?
Saturday, November 19, 2016 10:20 AM
Sorry but it appears that someone may be playing with you. Noting that has been posted here could possibly do that. Someone playing with AD could have done that or some other element of your configuration may have done that.
Again - this is why I constantly recommend that you learn AD and PowerShell before trying to do advanced automation. Just copying code without understanding how it works is a formula for confusion, anxiety and possible disaster.
"LogonTo/userworkstations" is an attribute that has never been used and cannot be set by accident. Perhaps you are not the only one experimenting with PowerShell.
I recommend that you stop and contact someone certified in AD to work with you until you understand how these things work. It is safer than being confused and guessing at things.
\(ツ)_/
Saturday, November 19, 2016 10:25 AM
no, completely impossible. I just could prove it. The -l attribute does not change city, but is a replacement for logonworkstation.
You can check it by yourself. And tell me you did'nt know that. Who is the expert that has learned everything? Seems I learned something in one night that is not published in the internet so far.
Very strange that a beginner like me finds this out, hm?
Saturday, November 19, 2016 10:28 AM
no, completely impossible. I just could prove it. The -l attribute does not change city, but is a replacement for logonworkstation.
You chose the "l" attribute. I changed it to City which is what the CmdLet wants. This is why I keep repeating that you need to read the documentation on each CmdLet and understand what you are doing and why.
Basic PowerShell - any parameter that resolves to a unique first few letters will be resolved as long as there is no conflict with any other parameter. -C would be Company, City or other parameter so -C will not work. -Ci would resolve to City only. It is always best to use full parameters in batch operations.
\(ツ)_/
Saturday, November 19, 2016 10:32 AM
I followed an article from microsoft where it said, one can read out the attributes from adsiedit to use it in ps. Therefore I did that.
There is no way to learn something right as long as infos from MS are regularly wrong!
So tell me, where is the -l discribed here??? I cannot find it
https://technet.microsoft.com/en-us/library/ee617215.aspx
https://msdn.microsoft.com/en-us/library/ms676847(v=vs.85).aspx
In another posting you link a user that asked how to reset userworkstations to default, to the second link I posted. There I cannot find how to reset to default. I just find infos how to change the default to something other. I cannot find a technet article that clarifies how to revert to default.
Please DO NOT TELL ME HOW TO REVERT. But if you have an technet article that explains how to use that parameter to revert the value to default, I would thank you! UPDATE: I just tried out what I learned this night. $null
I'm still looking for an official MS technet articles that teaches me how and why I have to reset it to $null.
Saturday, November 19, 2016 10:51 AM
This is because you lack the fundamentals of the technology. In PS we can use the attribute names in LDAP filters but not as parameters. Knowing what ADSIEdit is all about would allow you to understand what the statement about it was referring to.
There is only one parameter that begins with "l" and that is "LogonWOrkstations" so -l would resolve to that. It is not the parameter you wanted. "City" is the parameter in Set-AdUser that resolves to LDAP "l".
You cannot just assume things and articles can be misleading if you do not know the context of the article.
See: https://msdn.microsoft.com/en-us/library/ms676817(v=vs.85).aspx
Attributes in the schema are defined by an industry group and appear in all vendors versions of LDS (X.500). Each vendor extends the schema. Tools that access the schema also define alternate names for convenience. Tis is true of all vendors and all tools. You are used to the GUI which is a translation of the standard for visual ease of use. ADSIEdit uses schema attribute names and Active Directory allows for alternate names.
These are al things you will learn when you take a course in AD or become certified in Windows Domains. You cannot guess your way through this.
\(ツ)_/
Saturday, November 19, 2016 10:54 AM
Again - the article is Set-AdUser - https://technet.microsoft.com/en-us/library/ee617215.aspx
Help Set-Aduser will tell you how to manage AD user attributes.
\(ツ)_/
Saturday, November 19, 2016 10:59 AM
I just tried out what I learned this night. $null
I'm still looking for an official MS technet articles that teaches me how and why I have to reset it to $null.
Get-AdUser -filter * | Set-ADUser -LogonWorkstations $null
\(ツ)_/
Saturday, November 19, 2016 11:10 AM
No. This was never handled in the courses that I made in Germany, you have to teach that yourself.
I am MCSE 2003 (since 2008), have all upgrades to MCSA 2008, and passed all but the 70-414 to "MCSE 2012" (I do not want to do that). I got lots of courses in different topics, but ps was never a big topic.
I also am certified in Exchange 2010 and 2013 Administration. Here I did already a lot with powershell, but most of it was exchange-related (I know, same syntax, same ad, but the topics where completely others (mailbox, statistics, right settings etc.)). I am not that newbee I seem to be, but I admit I am not very familiar to this ad handling with ps.
Nevertheless I do not see good reasons to make the ps that complicated. If I have a asdi - or LDAP naming attribute to be correct - I should be able to use that in powershell. Would be simple. Needless to create an alias-construct.
Meanwhile I made a script to revert all userobjects with ne $null to eq $null in logonworkstations.
Saturday, November 19, 2016 11:12 AM
I just tried out what I learned this night. $null
I'm still looking for an official MS technet articles that teaches me how and why I have to reset it to $null.
Get-AdUser -filter * | Set-ADUser -LogonWorkstations $null
\(ツ)_/
thanks. did that already, but filtered to objects with ne $null, but delivers the same result in the end.
But where is the technet article? Still impossible to MS to deliver an example. Ok.
Saturday, November 19, 2016 11:27 AM
I just tried out what I learned this night. $null
I'm still looking for an official MS technet articles that teaches me how and why I have to reset it to $null.
Get-AdUser -filter * | Set-ADUser -LogonWorkstations $null
\(ツ)_/
thanks. did that already, but filtered to objects with ne $null, but delivers the same result in the end.
But where is the technet article? Still impossible to MS to deliver an example. Ok.
I posted a link to Set-AdUser.
How could you get an MCSE without learning LDAP? I got my first MCSE on W2K and it was in-depth LDAP/ADSI and all. PowerShell allows both the CmdLets and ADSI. In ADSI you can use the ADSI nomenclature. There are dozens of articles on MSDN on ADSI and how to use it. Most of the examples are in C but slowly PowerShell has been added.
Formally studying PowerShell with any of a number of good books would also help. Anyone who has never scripted AD before will find all a bit difficult until the overall system of scripting and scripting with PowerShell is absorbed.
Here is a good resource: https://technet.microsoft.com/en-us/library/ee617195.aspx
Even when accessing SharePoint from PowerShell there are many technological disconnects due to the way the SharePoint people have designed the CmdLets. It is done this way it is done because of the kind of technology SharePoint is.
All future MS products will be PowerShell managed. Understanding the how and why of PowerShell helps in acquiring skill with new technologies as they are released. PowerShell attempts to make complex APIs accessible and safe. Some research and learning is still always required.
Take things slowly. Set up a VM with AD and experiment with PowerShell until it becomes clear. You will find that it al makes good sense and works extremely well.
I still tend to use ADSI from PowerShell because workstations do not have the AD CmdLets. Knowing PowerShell ADSI, AD and C# AD API have helped me to gain a very good understanding of the depth and complexity of AD. I did not learn it overnight.
\(ツ)_/
Saturday, November 19, 2016 11:53 AM
slowly? no time anymore. I am over 40, shall manage Cisco switches and NG firewalls, vmware esxi in depth, o365 in depth, exchange in depth, AD in depth, Office Products in depth, and deliver full support for anything that has a power-cable. Just not possible. There is only time to manage everything basically. I'm over 15 years in this business, have everything I needed learned by doing, this would have been by far enough to take 700 in every test. But most of them I got with 950-1000, because I learned what I didn't know. And no, I neither learned brain-dump q&a, that is too silly and doesn't help. I learned the topics as far as needed and possible in that time. Therefore I am familiar to LDAP and AD - but I managed it since ages with gui. PS was in exceptions... But yes, I proved myself before taking the exams. Because I was young enough and wanted it to know "in depth". I have my own AD at home with more than 10 users, had exchange-servers in all versions and some sharepoint versions running. big enough to have an all-day-test-environment. But not enough to have it necessary to use ps. So it is very surprising that powershell was never a big topic to mcsa 2008 and nearly-mcse-2012.
In MCSE 2003 there was no PS, so this came up with exchange 2007 to me, since then I concentrated on that topic. But I do not want and I cannot handle to learn anymore in depth, therefore I rely an some help. I try to understand every silly thing from MS, but honestly, since I am also somewhat familiar to linux and macos, I do not want to remember the by far worst methods that human being could create. And that comes from MS.
In the link you provided is no example how to set it to default. Neither is there a list of possible values. Just the content-type "string"...
Saturday, November 19, 2016 5:41 PM
In AD CmdLets "Set" $null always clears a defined parameter. For optional attributes the -Clear is required. -Clear can also clear the defaults if needed. It is useful when we want to clear a list of parameters as it reduces typing.
\(ツ)_/
Friday, January 20, 2017 6:13 PM
Hi,
You can use Powershell with Active Directory module (Require ADWS : http://technet.microsoft.com/en-us/library/dd391908%28v=ws.10%29.aspx).
Th Cmdlet you have to use is Set-ADUser : http://technet.microsoft.com/en-us/library/ee617215
I can't test right now but here is the way :
Import-Module ActiveDirectory $USERS = Import-CSV c:\temp\users.csv $USERS|Foreach{ Get-ADUser -filter {name -eq $_.name}|Set-ADUSer -TelephoneNumber $_.TelephoneNumber -MobilePhone $_.MobilePhone -StreetAddress $_.StreetAddress -City $_.City -Title $_.Title}If you have the SAMAccountname in your CSV :
Import-Module ActiveDirectory $USERS = Import-CSV c:\temp\users.csv $USERS|Foreach{ Set-ADUSer -Identity $_.samaccountname -TelephoneNumber $_.TelephoneNumber -MobilePhone $_.MobilePhone -StreetAddress $_.StreetAddress -City $_.City -Title $_.Title}Regards,
This doesn't do all the account.
It stop at
Supply Values for the following parameters:
Process[0]:
Friday, January 20, 2017 6:17 PM
Hi,
You can use Powershell with Active Directory module (Require ADWS : http://technet.microsoft.com/en-us/library/dd391908%28v=ws.10%29.aspx).
Th Cmdlet you have to use is Set-ADUser : http://technet.microsoft.com/en-us/library/ee617215
I can't test right now but here is the way :
Import-Module ActiveDirectory $USERS = Import-CSV c:\temp\users.csv $USERS|Foreach{ Get-ADUser -filter {name -eq $_.name}|Set-ADUSer -TelephoneNumber $_.TelephoneNumber -MobilePhone $_.MobilePhone -StreetAddress $_.StreetAddress -City $_.City -Title $_.Title}If you have the SAMAccountname in your CSV :
Import-Module ActiveDirectory $USERS = Import-CSV c:\temp\users.csv $USERS|Foreach{ Set-ADUSer -Identity $_.samaccountname -TelephoneNumber $_.TelephoneNumber -MobilePhone $_.MobilePhone -StreetAddress $_.StreetAddress -City $_.City -Title $_.Title}Regards,
This doesn't do all the account.
It stop at
Supply Values for the following parameters:
Process[0]:
Please don't attach a new question to another users topic. Open your own topic with full information.
\(ツ)_/
Tuesday, March 5, 2019 12:31 PM
This got me most of what I wanted and I updated the script for my use case so I thought I'd share.
What I had was existing users where we wanted to add a new IP phone system numbers and check their managers were set correctly
#####Update AD using csv file
$USERS = Import-CSV c:\Users\newuser\Downloads\update_ad.csv
foreach ($user in $users)
{
Write-host "$($user.givename) from csv being written to "
Get-ADUSer -Identity $user.samaccountname -properties *
if($u = Get-ADUser -Filter "samaccountName -eq '$($user.samaccountname)'")
{
$splat = @{
#
# These lines work for AMEND attribute already in database
#
#Givenname = $user.givenname
#Surname = $user.sn
#City = $user.l
OfficePhone = $user.OfficePhone
MobilePhone = $user.Mobile
manager = $user.Manager
#ipPhone = $user.ipPhone
#
# These lines work for ADD attributes not in database
#
replace =@{ipPhone = $user.ipPhone}
}
##$u | Set-ADUser @splat
Write-host "$($user.samaccountname) updated"
}
else
{
Write-Host "User not found $($user.samaccountname)"
}
}
example csv has header row for variable names and single user (use it for testing!)
Because of the null problem I found it easier to fill null answers with "unknown" which gives a useful search for later completion
When you're happy unremark the Set-ADUser line above
samaccountname, Manager, reports to, ipPhone, OfficePhone, mobile,
test123 "CN=manager,OU=Users,OU=All Sites,DC=example,DC=com" manager 374 0131 123456 unknown