Say you update your phone system or you merge with another company and have to update phone numbers in your AD address book without having to do it manually. PowerShell to the rescue.

First you need to create a .csv file with all the names and new phone numbers that you want the users to be updated to. It should look something like this:

user,phonenumber
Dan O'Neill,+353 1 234 5678
Brad Pitt,+353 1 123 4567
Frank Bruno,+353 1 235 6789

This will be read by the PowerShell script. Reading in files in PowerShell is simple to understand. All you really need to know is that it reads files line by line and sometimes there are even cmdlets that will look after the import for you. In this case we can use Import-CSV.

$userlist = "C:\temp\import.csv"
$UserDetails=Import-CSV $userlist

Nice and easy – then we need to iterate through this list and actually do what we’re looking to do – Update a large list of users in AD with PowerShell – in this example, update everyones phone number.

So, as we’ve imported the csv file we’re then able to iterate through it line by line. As we move through it, we assign the value to a variable. Like so:

foreach($UD in $UserDetails) {
	$user = $UD.user
	$phnumber = $UD.phonenumber

The next stage is the first time we connect with AD and it’s quite an important part of the script. We want to check that the user in the file is an actual user in AD. In this case, I’ve been given names – so I check this against the CN in AD. However, you could check against any unique field in AD like username(SAMaccountname) or something like that. The following line assigns TRUE or FALSE to our variable $UserN:

$UserN=[ADSI]::Exists("LDAP://ad.domain.com/cn=$user,ou=Users,dc=ad,dc=domain,dc=com")

Then comes the actual interesting bit. We check whether that has come back with false…

if($UserN -ne $FALSE){

…and if it hasn’t then we apply the changes that we need to.

$UserN=[ADSI]"LDAP://ad.domain.com/cn=$user,ou=Users,dc=ad,dc=domain,dc=com"
$UserN.Put("telephoneNumber",$phnumber)
$UserN.SetInfo()
write-host $user "has been modified"

Very simple and straight forward. And since we want to be able to tell afterwards which users worked and which didn’t, the other part of that if…else loop looks like this:

}
else{
        write-host $user "object does not exist" -foregroundcolor red -backgroundcolor yellow
}

This prints out to your console in nice red font and yellow background which users failed to update.

In full the script looks like this:

$userlist = "C:\temp\import.csv"
$UserDetails=Import-CSV $userlist
foreach($UD in $UserDetails) {
	$user = $UD.user
	$phnumber = $UD.phonenumber
        $UserN=[ADSI]::Exists("LDAP://ad.domain.com/cn=$user,ou=Users,dc=ad,dc=domain,dc=com")
        if($UserN -ne $FALSE){
		$UserN=[ADSI]"LDAP://ad.domain.com/cn=$user,ou=Users,dc=ad,dc=domain,dc=com"
		$UserN.Put("telephoneNumber",$phnumber)
	   	$UserN.SetInfo()
		write-host $user "has been modified"
	}
        else{
            	write-host $user "object does not exist" -foregroundcolor red -backgroundcolor yellow
        }
}

One thing that I’ve come across recently from a bit of a odd situation is the Bypass traverse checking group policy object.

Basically, what this allows users to do, is traverse folders that they should have no access to…

This is how it is explained in Microsoft’s technet article about it…

This user right determines which users can traverse directory trees even though the user may not have permissions on the traversed directory. This privilege does not allow the user to list the contents of a directory, only to traverse directories.

This normally would bother anyone, unless during a very sensitive data move that requires you leave the permissions of the underlying data alone. In this case, you have a top level folder with a certain set of permissions but because of an audit rule you have to leave the permissions on the lower level folders alone for a period of time.

You would expect the users not to be able to get to the data below the top level folder – why should they? You’ve set the permissions correctly on the top of the folder and then the Bypass traverse checking group policy object steps in. And ruins your day.

Slight exaggeration, and easily dealt with since we don’t knowingly use this GPO for anything else in the server. This is the default user set that can, by default, gain access via this group policy:

• Administrators
• Backup Operators
• Power Users
• Users
• Everyone

Out comes the “everyone” group, and now we’re nicely audit compliant.

Normally this would not be a problem as most of you will force replication after a folder move, thus inherit the permissions of the top level folder and block the user from traversing the folder as they will have no access to the folder below the top level.

Obviously, the first suggestion was to go to each PC and start a search. Ouch. That would have taken an age and would have to be done when no-one is at the desk. And with hundred’s of PC’s to look after this really wasn’t a good idea.

So, wanting to show off my meagre scripting skills (but mostly to avoid walking around the entire office) I said that I would be able to script a solution to search every PC remotely. Although, I’m pretty good at scripting  pretty simple tasks, I had no idea if I could do this.

First, I had to see if I could search my own PC with a command line tool. I considered a couple of options – either FIND or FINDSTR. I decided to go with FINDSTR as there are loads of options and useful switches. I also wanted to reduce the time it would take to search my PC. I took a look at the security settings and basically decided that it would be a waste of resources to search every file and folder on the PC as our PCs are locked down so that users only have write permission on certain folders. So I could narrow the search down to those folders. So part 1 of my script became:

findstr /s /M /D:c:\Temp\;c:\docume~1\; /C:”Phrase to Search For” *.xls

Let me explain the switches in use here:

• /s – Search all subfolders
• /M – Only print out the filename of files that contain the phrase. The default is to display where in the file it is too.
• /D: – The directories to search in a list separated by semi-colons.
• /C: – The literal search string
• and the last option is the files to search. In this case – all files that have the .xls suffix. i.e. Excel files.

This line worked excellently and produced the following output:

c:\Temp\:
c:\docume~1\:
username\Local Settings\Temporary Internet Files\OLK10\stupidfile.xls

This shows that it found a file in my documents and settings folder with the above phrase in it. Excellent, so now I could move onto the next task – running this script on every PC and with admin rights, so that every folder could be searched.

In steps the Systems Administrator‘s best friend – PSTOOLS. Literally the best selection of admin tools for the Windows Systems Administrator, from the legendary Mark Russinovich. One of them – psexec.exe – does exactly what I need it to do. It allowed me to send out the above bat file to a huge list of machines and run it remotely using whatever user account I need to.

psexec @list.txt -u domain\adminadccount -d -c search.bat

Let me explain the switches in use here:

• @list.txt – basically this list contains every machine that you want to run the command on.
• -u – this allows out to stipulate the account to run the command under. In this case the fictional domain\adminaccount account
• -d – dont wait for the command to finish before carrying on. I was able to do this by using the bat file to output to a cetral location.
• -c – this switch copies the following bat file locally to the machines in question before running it. This is important because I had local drives specified in the bat script.

This ran on the test machines fine. Next stage was to pipe the output to somewhere nice and central and in manner that would allow us to differentiate the output from each machine. You couldn’t output everything to one file or you would have different machines outputting to the file at different times so depending on when the search was started it would output at different times and the file would become unreadable and full of meaningless data.  To avoid this I did a little roundabout way of outputting to files. I did this by getting the bat file to create a txt file based on the PC name:

echo %COMPUTERNAME% >> \\centrallocation\%COMPUTERNAME%.txt
findstr /s /M /D:c:\Temp\;c:\docume~1\; /C:”Phrase to Search For” *.xls >> \\centrallocation\%COMPUTERNAME%.txt
If %ERRORLEVEL% EQU 0 ECHO %COMPUTERNAME% had a copy of the file >> \\centrallocation\overall.txt

Note – The above should only be three lines. This was the full search.bat file but let me explain it:

First line created a file called computer name and on the first line of that file wrote the computername. You may not need this but for peice of mind I did this to be able to show management that it actually ran on the machine.

Next line outputs the findstr command from above to that same file. Often this would just output two lines with the directories searched as nothing would be found on the machine. However if the file was found it would also output that information.

The next line is very important. It is what the entire bat file relies on to make it simple for you to find the machines with the file. Even though the line above has created files for every PC, and all the information is held within them, it would be a very timeconsuming task to go through each one. Basically if findstr doesn’t find a file that you’re looking for it will change %ERRORLEVEL% to greater than 0. If it does find it however find a file the %ERRORLEVEL% will be 0. So if that is so then we output the computername to a file called overall.txt. This then gives us a list of PC’s where the file was found and we can then go to the corresponding computername.txt and find the location where the file was found.

So that’s how I did it. I wouldn’t mind hearing any different ways to do it from anyone out there so get in touch in the comments.

So normally, I’d open up a console RDP session to the win2003 server using mstsc /v: servername /console. This connects to session 0 on the box and allows me to disconnect the session and leave it running overnight and not have my session time out and cause the job to fail. However recently I updated mstsc.exe on my machine to version 6.0 to resolve another problem I was having remoting to my XP machine from my Vista PC at home. However it appeared that the /console switch no longer worked. Also when the /? switch was used, it wasn’t even mentioned.

This creates a problem in that I couldn’t connect to console sessions to complete long tasks. However, while looking at the above instructions I noticed the /admin switch. Did they just rename it? I tried it and excellently I was able to log on to a console session created with the old mstsc application using the /console switch. Brilliant news. So to connect to any console session on a win2003 box all I had to do was mstsc /v: servername /admin. I decided to follow it up however to see why the change was made and if indeed if any change was made. I came across the following article http://blog.shijaz.com/2008/01/no-more-mstscexe-console.html which explained the situation with the application and why the change was made. Also, this is going to come up even more with the increased uptake of windows server 2008, as explained in the above article. It makes for an interesting read and explains Microsofts thinking about how console sessions will work in future (i.e. not at all ).