Wednesday, March 12, 2014

3 Lines of Code, So Many Possibilities.

I have struggled within my company with trying to make bulk changes to AD objects, and of those objects, mainly AD users. I have 250 users within my AD environment, not really a large environment, ut large enough that with me being the only System Administrator, making a change of more than 5 users becomes time consuming, and labor intensive. Two things I don't have much extra to spare. What drove me to make this script was having to change the ProxyAddress attribute on every user within my AD. This was due to Office 365 inputting the wrong data into that field, and borking the domain that my internal emails were being set under. After looking through many Technet postings, and bashing my head against the PowerShell wall for an hour. I put together this snippet of code.

ForEach-Object ($user in (Get-ADUser -filter *))
{$newinfo= "
Replacement Data String Here"
Set-ADUser $user.samaccountname -replace @{ADAttribute>=$newinfo}}


First thing you will notice is that it is very short, and that is one of the beautiful things about PowerShell, you can do a lot in a very small amount of code. I have found that most of the time I try and write two much code, when a very short two - five line script will do everything I need and more. So let's dive into what this script does.


Line 1


ForEach-Object ($user in (Get-ADUser -Filter *))

The ForEach-Object command allows us to do two things.
>
  1. Run an operation or query defined within the parentheses after the ForEach command, that pulls some sort of data. In this case that query is Get-ADUser -Filter *.
  2. The second is that you can then run a second operation or query against the first query, in a nested query sort of fashion.


($user in (Get-ADUser -Filter *))

The second part of this line takes the results of the Get-ADUser -filter command, and drops it into a variable called $user, storing the data from the Get-ADUser command and then allowing us to preform an operation against that data later. The * at the end of the -Filter command is a wildcard in PowerShell. It causes PowerShell to use all data that the command has access too.

You can change the * to get a more specific set of objects by adding a better filter, and a different wildcard. Some examples of filters and wildcards you can do are:

($user in (Get-ADUser -Filter {Name -like “*e”))  #This finds all of the AD attribute Names that end in e.

($user in (Get-ADUser -Filter {Surname -like “d*”)) #The second filter finds all AD objects with Surnames that start with D.

($user in (Get-ADUser -Filter {Surname -like “*d*”)) #The third filter finds all AD objects with a Surname that contain a D in them.

The Second Line


$newinfo= " Data string replacement here"

This variable is where you put the data that you want to replace in the attribute. You can place any type of string in this field, and PowerShell will replace it in the attribute field.


The Final Line


Set-ADUser $user.samaccountname -replace @{ADAttribute=$newinfo}}

The last line of this command is where all the hard work is done. First off it starts by using the Set-ADUser Command. Set-ADUser is the main command that you will use when editing existing users within Active Directory. Through this command you can edit every attribute of every user within your AD environment. Sexy Huh?

The Set-ADUser requires us to specify a unique user to be edited, so we provide that user by using the data we pulled into the $user variable. But if you look at that data, which you can do by typing $user in the PowerShell windows, you are going to see that it pulled upwards of 10 attributes from all of your users. This amount of data is great, but we need to narrow it down to one field that is unique to each object. When I need a unique attribute I almost always use the SamAccountName attribute. This field is required to be unique by AD thus always providing us with that unique field we need. To do this we attach the attribute name to the variable with a period, this gives us $user.samaccountname.

-replace @{ADAttribute=$newinfo}}

Then we use the -replace flag for the Set-ADUser command, and add a filter to pick the specific attribute we want to edit. Where I have put ADAttribute is where you want to put the exact name of the attribute you want to enter. Some examples to give you an idea are:

if you wanted to edit the email attribute under all users it would be:
-replace @{mail=$newinfo}}

If you wanted to change the Office of a group of users it would be
-replace @{Office=$newinfo}}

Putting It All Together. 

Now I know if you are still reading this, you're questioning, okay so what does it look like when it's in a script and I want to use it. So here are a couple of examples and what the do.

 ForEach-Object ($user in (Get-ADUser -filter *))
{$newinfo= "Contoso, Inc."
Set-ADUser $user.samaccountname -replace @{Company=$newinfo}}

This version of the script pulls all users from AD and replaces the Company attribute in AD with Contoso, Inc.

ForEach-Object ($user in (Get-ADUser -filter {Office -eq "Miami, FL" ))
{$newinfo= "Jacksonville, FL"
Set-ADUser $user.samaccountname -replace @{Office=$newinfo}}

This script pulls only users who have "Miami, FL" in the office attribute, and changes it to "Jacksonville, FL".



Thus you can now see the true power of this command. It allows you to change any attribute within your AD infrastructure, over a group of users, and when I ran this command against my entire AD, which has 300 active, and inactive users, it took less then 30 seconds to edit all the accounts. Something that would have taken me 6 hours in the GUI!!! I hope that this information will make you life much easier, and wet your appetite for learning about PowerShell.

Thursday, December 26, 2013

WSUS: More then just a Microsoft Update Platform

I HATE JAVA!!!! There I said it. I absolutely despise Java as a system administrator.  Java is the only program I have found that has an entire website dedicated to a zero day counter for the product. (www.java-0day.com/). I mean as we speak Java 7 is on update 45! On top of that, Java is a required application on my company computers, as one of our major cloud based programs runs completely on Java. But the update schedule of Java is something that we have always struggled with as a company for a few reasons:
  1. We are still working to gain full command and control over our systems. The previous IT manager didn't feel that total command and control over computers was really needed, so I still am working to bring all computers under domain control.
  2. Because we are a 2 man IT shop, and honestly we have been so swamped trying to fix our larger IT issues (see item number 1), that patching has unfortunately went by the way side.
  3. No command and control = Sneakernet for updates.
Well Microsoft went out and released IE 11. IE 11 now verifies your Java version, and if it does not feel that the version of Java on your computer is up to date, it blocks Java from running. This is a big problem, because as the computers we do not control over have automatically updated to IE 11, and thus Java has now stopped working. So I was forced to find a method to finally manage updates of Java, Flash, Adobe Reader, and the other non-Microsoft software that we have to patch.

While out searching for advice on patching software, I stumbled upon a answer to a post at Spiceworks. In it a user stated that they used a open source product call Local Update Publisher (LUP). I began to read the very small amount of documentation on the SourceForge website for this software. It had a Windows GUI, which is nice, seemed fairly straight forward, so I figured what the hell, I'll give it a shot. To be honest it took me about 2 hours of tinkering and messing around following the documentation to get things up and running. And for it's price, this product has completely blown me away. I am able to publish an update for Java, Flash, Acrobat Reader, or just about any program that comes in an MSI form, in less then five minutes, and then approve and push those updates on schedule with my existing WSUS settings. What follows are the steps that I had to take to get LUP up and running. Feel free to use this as needed, I hope that I can knock your setup time down to an hour or less, and save you some budget so you can buy your CEO a new iPad Air thus making you the nicest IT guy on the block.

If you want to just figure it out on your own, and not read the rest of this article, which I would completely understand, then you can head to LUPs SorceForge Page. There you will find good install instructions, below I have just attached screenshots to help you out.

 

Installing and setting up Local Update Publisher (LUP)

First you must have WSUS set up, and I'm going to assume that you have this step done, as there is not enough space in this post to walk through a WSUS install.

Fist step is to download the LUP files, you can find those at this link.

On either a computer running the WSUS administration console, or on your WSUS server, run the installer. I just next, next, finished through the installer.

After you have completed the installer you will need to run LUP as an administrator. If you don't, WSUS will block LUP from connecting to it. It took me 20 minutes to figure out the error that this causes, because the error doesn't pop up till three steps later, and makes no reference to this being the problem.

After you have started LUP you will see the dialog box below.



You can put the IP address or web address of your WSUS server into Servers field, or leave it as is if LUP is installed on the server WSUS is installed on.

You can choose to name the server in the name text box, or you can leave it blank. If you choose to leave it blank the server you connect to will be named local server.

You can change the port if you use a port other then the standard port, as well as use SSL if that's the flavor of WSUS you have installed.

After you have completed these steps the program will open up, you will need to double click on LOCALHOST, or the name that you put in for your server, to connect to the server. If you get an error that you are unable to connect at this point, and then LUP tells you that it wants to close out, verify that you are running the program as an administrator.


After you have connected to the WSUS server the following window will pop up, in the image above, you then need to click yes and you will be taken to a dialog box where it will ask you to either import (if you have an existing PKI or internal certificate system I am going to assume that you are able to import your certificate to the WSUS server, or have already done so in the past and will not need to complete this step) or create a new certificate for the server. If you choose to create the certificate you will need to export it, by clicking the export button in the dialog you will see below.


Follow the dialog box to save the exported certificate in a location that you can find later on. After you have exported the certificate you will need to place that certificate into a GPO so that it can be published to all of the computer.

To do this create a GPO, and then go to Computer Configuration/Administrative Templates/Windows Components/Windows Updates/Allow Signed Content from intranet Microsoft update service location, and set it to enabled.

Then go to Computer Configuration/Windows Settings/Security Settings/Public Key policies  and import the certificate to both "Trusted Publishers" and "Trusted Root Certification Authority"

Save the GPO and assign it to a group of test computers that you want to test your updates on.

 

Creating an update in Local Update Publisher (LUP).

After you have completed the above steps we will proceed to set up an Adobe Flash update, it is the same process for Java or any other program/update that you want to push via WSUS. The LUP documentation provides an overview of how to build the major third party updates here.

So your first step is to open Tools, and then select Create Update, as seen below.


The window in the image below appears, in the update file line, via browse, point to the location of your update file )I host all of my GPO and update files on a hidden file share that all computer and users have access too). It will have to be an MSI file type for the program to find it. Adobe files can be found for download at  ftp://ftp.adobe.com/pub/adobe/. After you have linked the file click next.


In the next window, you will need to input the vendor and product name as they are required, also make sure to select the reboot action that you want the update to perform.


In the next field you can create rules as to what computer the update effects, allow it to skip computers if it possess a certain program, or version that you do not want WSUS to update. The sky is the limit with the settings that you can use here. I personally did not mess with any of these settings.


Again the next window allows you to be modify the updates behavior based on metadata if there was a previous installation, and you are wanting to update it.


This last windows contains all of the XML data that WSUS uses to be able to run the update, and parse our which computers to install the update too feel free to edit this at your own risk. I'm not an XML guy, so I just leave it alone.


Click finish, and you will see the update appear in the left hand window under Local Host > Updates > Vendor > Product Name. You can then choose to approve the update, and use any of the existing computer groups that you have to apply the updates, the update approval uses the same dialog that WSUS uses when you are approving Microsoft updates.

Also on a small side note, any update that you create in LUP will not show up in the WSUS console, at least not anywhere that I have been able to locate. You also have to use the LUP console to verify the status of the published update. If you select the update, and then the status tab in the lower right hand window, it will show the status of how many computer are updated, failed, etc.

I have been using this for around two weeks, and it has changed my patching life, I was able to update all of my domain computers, and it took me all of  5 minutes to create the update, approve it, and push it out to the end users computers. And it cost me 3 hours of my time, and no capital outlay to get this patching operation up and running. I hope you find this as useful as I have. Please feel free to leave any comments about your experiences with this product.

Tuesday, December 24, 2013

The Zen has Begun.

Welcome to The Zen of System Administration. My name is Dominic, I am a very young (29) system administrator/IT manager for a small non-profit company. I endeavor, with this blog, to document tricks and processes I find that have allowed me to become more knowledgeable, more productive, generally for the least amount of money possible.

So a little about me. I generally specialize in Microsoft Server products, VMWare Infrastructure, and Windows Operating Systems. 3 years ago I was a help desk technician for the company that I currently work for. Due to a series of crazy events, I have worked into the job of IT manager/System Administrator, I have my MCITP:SA (damn that's a lot of letters) 2008 R2, Citrix XenApp 6.5 CCA, and am working to upgrade that mouthful of letters to a MCSE Server 2012.

I plan to document my continued certification experiences, products that I implement for the company I work for, review technical books that I read, and provide well documented how-tos to save you time and hopefully money with your system administration challenges. I hope that you find the content on this blog to be useful, educational, and fun.