Vista Service Pack Deployment - Remote Installation of Vista SP2

Remotely Install Vista Service Pack 2 in only 5 Steps

This step-by-step, and the included video, will demonstrate a remote installation of Vista SP 2 to multiple computers, simultaneously.

NOTE: Vista SP1 must be installed before applying Vista SP2.

• Download Vista SP1
• Download Vista SP2

NOTE: If you aren't certain of the version of Vista service packs that are currently installed, you can use a free 30-day trial of Admin Arsenal, our system admin product which scans computers for installed software.

Now, let's get to work and install Vista Service Pack 2.

Step 1: Select the Vista SP2 install executable

Click on the elipses button and navigate to your downloaded exe for SP2. Since this installation requires only one file, you do not need to select the "Include Entire Directory".

Step 2: Enter the Command Line Parameters

Enter the parameters into the Command Line Parameters field (shown above).

/quiet /norestart

Here is a list of all the command-line options available when remotely deploying Vista SP2.

Step 3: Select Target Computers

Select the button "Create Deployment". The next screen appears and you are now able to enter (or select) the target computers to deploy Vista SP2 to.

You have four methods of selecting target computers.

1. Manual Entry
2. Import a Text File
3. Active Directory
4. Admin Arsenal

Step 4: Select Authentication Account

Select "Next Step" to choose an account to perform the installation. By default your current account is selected.

Step 5: Deploy Vista SP2

Click "Next Step" and you'll see a verification page for this deployment. If everything looks good then you may start the deployment by clicking "Deploy Now".

Your computers will now receive the upgrade. The status will be shown within PDQ Deploy.

This installation is moving a lot of data, plus the installation itself is rather involved. Plan on between 30-60 minutes for each computer.

NOTE: The command line parameters that we supplied suppress any required reboot. It is highly recommended that you reboot your workstations as soon as possible following the service pack installation. If you are able to do the installation off-hours then you may wish to use the /focerestart option.

You know, working after hours reminds me of a maintenance window I performed about eight years ago. Another sys admin was joining me and we had arranged for him to bring in some food for the long night ahead of us. He brought me 20 tacos from Del Taco. TWENTY. They weren't for both of us, they were for me. Just me. I was floored. I think I was able to eat maybe two of them.

I never found out why he brought me so much. Perhaps he had spatial issues and had a difficult time correlating the size of my gut to the sheer amount of ground corn and beef that constitutes twenty tacos.

Anyway, I digress... we're done with the deployment of Vista SP2.

If you are using the free version of PDQ Deploy, the installation will continue in increments of eight computers.

 

 

Using PDQ Deploy? It's free and available right now.

 

---

Follow me on Twitter:@ShawnAnderson

Google Command Line - System Administration Tool I Didn't Know I Needed

Every now and again you run across a utility that you didn't know that you needed. The Google Command Line (HT: Everything Sysadmin) is one such tool. It provides access to a number of Google services, and looks to be something that is going to grow over the years and become powerful. Right now it's very handy if you need to work a lot with Picassa, Blogger, Google Docs, Contacts, Calendars, or YouTube (see some more examples.)

It requires Python, which I don't have installed on my Windows machine but I did have on my Mac. It installed fine with the standard Python on the Mac and after some confusion about my user account (I regularly log into Google with 3 different accounts) I was able to get it working and it's pretty slick. 

I downloaded Python and installed it on my Windows 7 workstation to see if I could get it working. Clearly I was missing a step somewhere because I couldn't quite get it to run, but it appears to be that I'm missing some Python libraries that are installed on my Mac. I didn't spend much time troubleshooting it because I will only be using it from my Mac, anyway.

What intrigues me most about it is the gdata API libraries for Python that it uses which I didn't know existed. Now that I know about them, I can think of a number of interesting uses. There's a lot more in the libraries than is exposed through the command line tool. Some powerful Google services that I didn't even know existed. I'm going to curl up with a hot cuppa and read though them and get some fun ideas.

Random Thoughts on the Sys Admin scene

If Apple = gay and Windows = straight would that make Linux = abstinence?

I saw Office Space for the first time 3 years after it was released.

I weep (OK, maybe not weep, but I definitely roll my eyes) at the lack of troubleshooting skills prevalent amongst many in the Sys Admin community.

I love to script and to solve technical problems but I am lazy as hell at documenting fixes, work-a-rounds or solutions.

I feel that if most Sys Admins had a soundtrack it would sound like AM radio.

Most of the amazing Sys Admins that I have met have either no college degree or a non IT degree. (Philosophy, Poetry, Chemistry immediately pop to mind)

I've know two Sys Admins who have had AS/400 computers in their bedrooms (yes, they were married)

Many Sys Admins save every script they have ever written.

I prefer PowerShell, VB, WinBatch, Python, Perl and mashed potatoes to VBS.

Planet Tivoli conference in 2002 had a dance for its attendees. A dance! The ratio between male sex-starved basement-dwelling gamers to females had to be at 100 to 1. Those poor, poor women.

I once shot a server just to watch it die.

The most common reason for becoming a "civil servant" that I hear from techies is some variation of: "Because you can't get fired". I'm sorry, but if "you can't get fired" is the primary reason for a sys admin to take a job I don't want that sys admin ANYWHERE near my servers. 

I think I'll join the Pirate party.

Remotely Install Office 2010 - Part 2 - The Deployment

Our previous post discussed using the Office Customization Tool for Office 2010. Now that you have your custom .msp file, you are ready to remotely deploy Microsoft Office 2010.

Ensure that your customized .msp is in the same directory as your setup.exe. We named ours custom-office.msp.

Step 1 - Choose Install File

Using PDQ Deploy, select your setup.exe by clicking on the elipse button.

Be sure to select the "Include Entire Directory" check box. Next enter your msp information in the "Parameters" box.

/adminfile custom-office.msp

Because our .msp contains all of our customizations, including installing silently and entering the license key, we won't need to add any additional parameters. 

Go ahead and select next step to choose which target computers receive the installation. You have four options to select target computers:

• Manual hostname entry
• Import a text file
• Active Directory
• Admin Arsenal Collections

To change the account that you will install Office with, select "Next Step", or if you are already logged in with that account, go ahead and select "Deploy".

Your installation will begin. It can take a little while for Office to install, depending upon which features and products you are installing. A full installation can easily take over 30 minutes. Your installation status will be displayed as it updates.

We have a video which demonstrates deploying Microsoft Office 2010 available from our YouTube channel (youtube.adminarsenal.com).

 

The secret to a successful Office deployment rests in using as many .msp's as your organization needs. Afterall, users have different needs. If they simply won't be using certain products in the Office suite, don't install those products. It can simply add clutter to their program menu.

Also, testing is important, especially if you are upgrading to Office 2010 from Office 2003 (i.e. if you skipped '07). The interface has changed quite abit between versions '03 and '10, so be sure your users are prepared for the change.

If you have any tips on successful deployments of Office, please let us know.

 

Deploying Microsoft Office 2010 - Customization and Deployment Methods, our newest White Paper, goes deeper into the Office Customization Tool as well as highlighting methods to deploy Office without disrupting users. Download your free copy today!

 

 

 

---

Follow me on Twitter: @ShawnAnderson

Software Deployment File Locations

One of the questions we often get about Admin Arsenal and PDQ Deploy has to do with how the installer files get to the target computers. There are two different ways to install software on a computer over the network, each with strengths and weaknesses. The choice whether to copy the installer files to the target machine before installation or to run them directly off of a file share is not always obvious. Neither option is perfect for all situations and some of the considerations are:

1. Security. Network policies may prevent running executables over the network. This can be a particular problem with deployment tools (more on this below.)
2. Performance. Depending on what is being installed, its size, or how the installer was built - one method may be faster than the other.
3. Disk space. Installing directly from the network typically takes less space during the installation.
4. Bandwidth. Copying first and then installing uses bandwidth in a more predictable fashion. A file copy can be throttled and managed (with a deployment tool or file copy utilities like Robocopy) while an installation reading directly from a file share can't.
5. Installer requirements. Some installers have problems when run over a network, but this isn't very common. Others must be run from a share, there are some Office administrative installations that require this.

Admin Arsenal and PDQ Deploy both use the option of copying the installer files to the target computers to install. We did this for two reasons. First, it's the best option in most situations. Most installers are small enough that any extra overhead won't be noticed, there's less to do to get it running without having to set up file shares and permissions in advance, and installs can be copied directly from an administrator's local disk. The other reason is that it's easy to install directly from a file share when necessary while still using this method (while the the reverse isn't always so easy.)

Installing from a File Share

It's actually quite easy to install from a file share using Admin Arsenal and PDQ Deploy for those situations where you need or want to. There are two things that you need to do.

First, create a batch file that will install from the file share (use a .bat or .cmd extension.) This batch file can then be installed and it will be copied to the target machine and not the installer itself. The batch file could be something as simple as this:

\\server\share\installers\setupapplication.exe /s

You will still need to be aware of silent command line arguments like you would when installing directly. If the installer is an MSI file, though, you will need to run the installer with msiexec.exe instead of directly. You can find the exact command-line you need by creating a deployment in PDQ Deploy or Admin Arsenal and seeing what the full command line is:

PDQ Deploy

Admin Arsenal

Just put in the name of the MSI file:

msiexec.exe /i \\server\share\installers\setupapplication.msi /q /norestart

You can also do a number of other things in the batch file such as set environment variables, map network drives, and run several installs at one time. I'll have some blog posts on these more advanced topics in the future.

The second thing that you need to do is to properly set the authentication used during the install. When installing software remotely there are three different types of credentials that can be used:

1. A standard service account. This is usually Local System or Network Service. Neither of these accounts are going to have the sufficient rights to install software off of a share (this can be changed, but it's not something that is typically done in most environments, it's best to assume that no access will be allowed.)
2. An secondary token or impersonated account. Running an installer through WMI uses this method, it's a feature of the Windows networking infrastructure. Impersonated accounts don't have the necessary access to run installers from file shares. This is something known as the "double-hop" problem because the security token used by an impersonated account can't itself be impersonated and make that second hop to the server, the first hop being from your workstation to the target computer. (This can also be changed but it requires configuring a Kerberos server to allow "delegation" which a very specialized thing only for the very brave.)
3. A primary token. Primary tokens can be used to run installers off of file shares, these can only be used if the application has the user's password. When you log into your workstation you are giving your system your password for a primary token and that's why you can access network resources. Admin Arsenal and PDQ Deploy can both create primary tokens by using the "Send Password" check box in Admin Arsenal or the "Use Other Authentication" option in PDQ Deploy. You will need to use one of these options to ensure that the batch file can access the files off of the share.

With a batch file in hand and the right authentication setting you will then have the best of both worlds: Copy the files to the targets for most deployments to keep things simple but have the power to use file shares when needed.

As always, feel free to drop by our Forums if you ever need any help with a specific installation. Happy deployment!

PowerShell Tip: Default Parameter Values

If you've spent any time working with PowerShell you've probably built a function or two. Function parameters are a handy way to make general purpose functions that can be used in a number of different ways. Consider, for example, that you have a function that restarts a service that, for whatever reason, is misbehaving. You could have this:

function RestartService($name) {

net stop $name

net start $name

}

Sometimes you need to add a sleep between the start and stop to make sure that the service comes back up correctly, but you don't want to make a new function (one that sleeps and one that doesn't) so you add a new parameter.

function RestartService($name, $sleep) {

net stop $name

sleep $sleep

net start $name

}

This works great, except now you have to pass in a 0 most of the time, and only use the sleep parameter on those rare occasions. To fix this, you can make the $sleep parameter default to 0 so that if you omit it you don't get a sleep.

function RestartService($name, $sleep = 0) {

net stop $name

sleep $sleep

net start $name

}

This will give you the flexibility you need.

# Don't sleep

RestartService SomeService 

# Sleep for 10 seconds before restarting

RestartService SomeService 10

University Degrees in System Administration

In a recent talk Bill Gates said that most future post-secondary eduction will be coming from the web. One of the big reasons was that university costs are just too high, and I agree with that sentiment. Costs to attend a university are rising at a rate that is far outstripping inflation. Costs are going to have to come down, and one way for that to happen is for much of the learning to move to the web.

But I also think that a big part of it is the rapid acceleration of specialization and innovation. It's one of the reasons that a university degree isn't such a big help in securing a system administration job. Experience is more valuable because the relatively slow moving curricula of a university can't keep pace with what's happening in the real world. Innovation of this type is leaking out of high-tech and into every industry. A standard degree will remain important for many fields, such as structural engineering and brain surgery, but much of the knowledge that surrounds the core fundamentals is going to become more and more difficult to contain within a structured university program.

I can see many university degrees becoming more like certification, where the degree exists to certify that a person has achieved a certain level of aptitude regardless of whether it was achieved in a classroom or in "the field." (Not like an MSCE, though, more like a CCIE or perhaps several CCIEs.) I don't know what form this type of degree would take, exactly, but I can't see the hard bond between a good job and a degree continuing to last as university costs continue to rise so sharply. Something's gotta give. System administration (most computer jobs, actually) are doing well without such a big need for a diploma, so it must be possible.

TechNet 2.0 - All New for System Administrators

If you haven't noticed TechNet got a complete facelift earlier this year. As a developer for Windows I visit TechNet at least once a week, nearly as often as I visit MSDN, and I think that the changes have been positive. It took me a bit to find out where things had moved, but it seems to be more logically laid out now.

The new TechNet Wiki should end up being a great resource in the future as more and more information gets added by the community. I find that I get nearly as much information from user comments on MSDN programming articles as I do from the article itself, so I'll be keeping my eye on the Wiki in the future.

The other big thing is the Troubleshooting Search, or at least I hope it is. It's sometimes an exercise in frustration while I'm searching for an error message or code as I go through page after page of unhelpful information in Google. I haven't had a chance to put it to the test, but I will as soon as I have an error to track down. 

For a good overview of the changes Train Signal Training has an interview with Keith Combs, one of the TechNet program managers. It's nice and short and gives a good rundown. They also have links to other details of what's new. 

Sober Confessions of a Sys Admin

In 2001 I took a contract with a company that wanted to deploy the Tivoli line of desktop management products. The Administrator community was quite hostile to the idea of using Systems Management tools from Tivoli. Many of these admins simply loved Microsoft. SMS 2.0, however, simply could not have met our needs.

Anyway many attempts were made to break the Tivoli agents (TMA). I ended up writing a little utility that I called MsLanMgr.exe. When I compiled the program I made sure the company data in the header read Microsoft Corp. and in the product description header I put a pathetically nonsensical string that I knew would placate (fool) any prying eyes. The description read: LDAP Binder for MS LAN Manager. This utility was called from the Run key in the registry. It simply repaired any damage to the TMA and, in some cases, it would need to reboot to have the repair finish successfully. I went digging through my archives and I found the utility. Here is a snippet of code where I checked the Local Security Policies (like Bypass Traverse Checking or Replace A Process Level Token).

 

OS=wntPrivGet("",GRP,OSK,0) ; Act as Part of the Operating System
QTA=wntPrivGet("",GRP,QTAK,0) ; Increase quotas
TKN=wntPrivGet("",GRP,TKNK,0) ; Replace a Process Level Token
TRVRS=wntPrivGet("",PUGRP,TRVRSK,0) ; Bypass Traverse Checking
LGNLCL=wntPrivGet("",PUGRP,LGNLCLK,0) ; Logon Locally

And a snippet from where I would log some info about tampering (and then reboot).

if TKN == @False
    TKN=wntPrivAdd("",GRP,TKNK,0)
    REBOOT = @True
    if DirExist(StrCat(CNLOGDIR,"\"))
        EPLOG = FileOpen("%CNLOGDIR%\%CN%.log", "APPEND")
        WRTDATE = FileWrite(EPLOG, "%IPADDR% %OSNAME% %DATE% Replace_Token_Key")
        FileClose(EPLOG)
    endif
endif

I find it hilarious that regular admins who were wary of Tivoli never ever questioned this utility. It was finally decommissioned later. The Tivoli implementation would have been VERY difficult were it not for this little subterfuge.

In 1998 some fellow admins and I noticed (from the Proxy logs) that a particular fellow seemed to have a penchant for viewing p0rn from his work computer. This was, of course, against company policy. Instead of running to the Director of IT we just decided to have some fun. One of our gang, ( a guy named Rich) noticed that this fellow stored many of the photos on his work computer in a seemingly innocuous named folder. Rich wrote a script that would traverse the p0rn folder and each .jpg would be opened by Microsoft Paint. When one photo was closed a new one would open up. We set the scheduler to fire off around lunch time. We waited. We got a call from one of the Help Desk operators. She said a that they just had an odd support call: A man breathing hard, who refused to give his name or Cost Center ID, asked what would cause pictures to just open up for no reason. When he was asked to describe the problem in more specific terms he hung up.

I never checked the boot logs but I bet he just powered off his Windows NT 4.0 machine. Heh heh heh.

Imagine what confessions I would spill if I played Adam's System Administrator drinking game...

---

Follow me on Twitter @ShaneCorellian

Top 10 Righteous Malware Uses

We all know that malware is evil, but like most evil things there are some valid uses for them (that's true, right? Evil things can have uses, even in a Time Bandits sort of way? I thought so.)

Well, in case you don't believe me, here are the top 10 uses for malware that don't require you to be evil. 

10. As a little present for the Nigerian 419 scammers when you send them your computer password so they can get your bank account numbers.

9. Any prank involving that guy from sales who keeps making fun of your tradeshow t-shirts.

8. Keyboard logging on your dad's computer so you can see what he typed right before "it broke and I swear I didn't change anything!"

7. Creating an unscheduled downtime emergency to get excused from a boring meeting.

6. Watching for references to computers on Hollywood scriptwriting computers and making the necessary changes so that the plot is somewhat in touch with reality.

5. Infecting the BIOS of your uncle's 12 year old Packard Bell computer so you can finally convince him that it's time to upgrade.

4. Making OS X feel more familiar to Windows users.

3. Showing up that obnoxious jerk at the class reunion by taking over the slide projector and showing Photoshopped pictures of him in his underwear.

2. Shutting down a real estate developer's computers to prevent the destruction of a building housing a rag-tag group of lovable orphans.

1. Defcon groupies.

---

Follow me on Twitter

Troubleshooting Systems Management or "Is my kid peeing in the pool?"

We were deploying Tivoli Management Agent (TMA) out to about 15,000 computers in 2001. There were about 170 administrators that were responsible for all these systems. There was A LOT of resistence from those administrators about adopting a centralized management system like Tivoli Framework. I will never forget one of the messages we received from an administrator who clearly had no concept of proper troubleshooting. The message, in part, read:

"We cannot install the TMA on our 230 computers because it breaks Oracle".

I replied with a request for her to be MUCH more specific. Her response was priceless:

"We feel that the TMA may be causing the Oracle client to lose connection to the Oracle database." (Italics added to demonstrate stupidity...I mean for emphasis.)

"May be causing ...?!" To paraphrase B.J. Honeycutt: "So far I have a definite possibility of three absolute maybes".

A co-worker of mine responded with the famous flea/cricket story used to demonstrate improper troubleshooting and to call her out on her text book use of the "post hoc ergo proctor hoc" logical fallacy.

A scientist taught a flea to jump on command. Out of curiosity he thought he would do some experiments with his trained flea. "Jump!" he yelled,  and the flea jumped six inches into the air. The scientist then pulled off two of the flea's legs and yelled "Jump!". This jump was only four inches high. He ripped off two more legs and the jump was reduced to two inches. After the last two legs came off the flea didn't jump anymore. The scientist then wrote a paper explaining how if you pull all the legs off a flea, the flea goes deaf.

Needless to say, this email didn't go over well but that's a story for another time.

My co-worker and I wrote another email detailing some things we wanted her to document for us.

1. Basic info: OS, Oracle client version etc.
2. How consistent are the errors? Are these errors present on multiple machines?
3. Please duplicate the error and send us the relevant Event Log entries.
4. Can you duplicate the error with the TMA service turned off?
5. Are there any articles on IBM or Oracle support sites documenting these problems?

There were a few more suggestions but you get the point. We wrapped it up with an invitation to come to their department and perform these tests ourselves.

We never heard back. The TMA was installed as planned.

I know, trust me, how painful it can be to have customers or end-users make blanket accusations or knee-jerk explainations of their problems. The most common is probably "The network is down!" because they can't get to a particular website or a print queue is backed up. The problem is that many of our management tools or configuration settings MAY be causing the problem that a user is experiencing. We have to remember that we have one or more swimmers in the public swimming pool that is a distributed computer environment. Maybe one of our swimmers is peeing in the pool. We can't have a knee-jerk reaction to what is perhaps the user's knee-jerk reaction because we may be at fault.

Keep the emotions in check, work the problem and save your frustrations and ranting for poker night or the occasional blog entry.

---

Follow me on Twitter @ShaneCorellian

Use PDQ Deploy to deploy software to your computers. It's fully functional, fully free and 99.6% urine free.

IPv6 System Management Successes

Back in July when I wrote about 5 Things This Procrastinating System Administrator has Learned I was pretty skeptical about the dire need to move to IPv6. I still am, but in the mean time I've been seeing stories about how some companies have been moving in pieces over to IPv6 and seeing how the move is going to eventuate. Everything Sysadmin has a good post on Successful IPv6 Projects which I think does a good job of outlining some strategies.

As I said before, I think that IPv6 was designed to avoid backward compatibility in a misguided strategy to get people to move over wholesale from IPv4. Whether this is true, or if there really are insurmountable technical limitations to backward compatibility, it doesn't change the fact that transitioning is difficult. Very difficult. Because of this, you don't see anyone drinking the whole jug of Kool-Aid and ditching v4 altogether. Instead, what you see are projects that transition to v6 with new devices or networks or with pieces that won't impact existing v4 users.

This is a good strategy because in doing so existing networks need to be upgraded to support the new standard in order to access the upgraded pieces. With a business case made, and a well scoped project defined, then an upgrade of a small piece of the network touches everything and gets the whole network ready to move. Since the real issue with v6 comes in interconnectivity outside of your network (read: Internet) being ready to flip the switch to v6 while still running v4 is really all you can, and need, to do for now.

At some point there are going to be two Internets, one that is v6 only and one that is still v4. There will be a lot of the Internet that can handle both but it can safely be considered the v4 'net. Once there is a critical mass on the v6 only side then any network which can't access it will be left in the dark ages. I still think we're very far away from that point, but now's a good time to start working on getting that little piece upgraded. Look for success stories out there, such as those on the Everything Sysadmin blog, to get some ideas of what pieces you can work on.

Remotely Install Office 2010 - Part 1 - Office Customization Tool

Prior to remotely installing Office 2010 to your company, you'll want to run the admin tool, also known as the Office Customization Tool.

We have a video which demonstrates using the Office Customization Wizard. We'll also show a step-by-step below.

Copy your Office 2010 setup disc to a folder on your workstation and open a command window. Change directories (cd) to your setup.exe location and run the following:

setup.exe /admin

The customization tool will open up.

Like most customization tools, there is too much to go through here, but we'd like to focus on the customizations that will make it easier for deployment without bothering your users as well as to disable some common "phone-home" features. (While these might be helpful features, some companies have policies against such feedback).

Hit the important areas to you, but be sure to select the "Microsoft Office 2010" selection, which contains some settings that are important.

After you've entered your volume license key, disabled the auto-start wizard, and disabled the phone-home settings, you're ready to make other changes as well.

Take the time to walk around the tool and see if there are other settings that would be helpful to you. If you have a SharePoint server this is a good way to customize the URL for your document library, etc. If you have an Exchange server this is also a fast way to ensure that all installations of Outlook point to the correct server.

To see the next steps showing the deployment of Office 2010 see Part 2 of this series.

A huge thanks out to the developers at Microsoft who continue to make this tool available. It helps those of us who rely on Microsoft Office everyday.

Do you need to deploy Microsoft Office to all your computers? Use PDQ Deploy, a free software deployment tool from Admin Arsenal.

---

Follow me on Twitter: @ShawnAnderson

Sys Admin? Join our Admin Arsenal Facebook page.