Software Deployment via Group Policy

I’m so excited! Today I discovered how to deploy software with Active Directory!

Disclaimer: this is NOT a manual or howto, it is just some notes from my experience.

I already knew that it was possible to install applications automatically using certain rules in AD, but it seemed quite complicated to me. I’d never touched a W2K3 before, and I don’t like to break things (even though I do it sometimes), so I kept away from the Windows servers. Today, after some months working with those machines, I got enough confidence to start looking around and find a solution. To which problem? Software deployment.

Currently, we install software from a share manually, and only some programs (like Office), are installed via AD. For new machines, we use a ghost image to install all software at once. However, software gets quickly outdated, and needs to be updated. I find really annoying to check and reinstall new versions every time. I lose my precious time and I always forget to install something. I prefer to dedicate efforts on solving infrastructure issues or experiment with new tools and projects. I really want to find a way to keep software organized, up-to-date, and synchronized. I was about to forget that one, I also want the same versions in all the offices. That’s another problem, because sometimes you update an application in the main office, but you forget about the others. It’ll be nice to have everything mirrored somehow.

I still have to think about the last issue, but I found some clues about keeping organized and up-to-date our applications. My first attempts have been quite a nightmare, with error messages in Dutch. Useless messages, like

“Application cannot be deployed because the application is not installed.” (original in Dutch)

provoke negative reactions on me and colleague, like

– “No te fot! Si lo que vull és instal·lar-ho!”

After fighting for more than 2 hours, trying all options, rebooting the computer thousands of times, we’ve given up. But then I found a book about Active Directory Infrastructure. One of those Microsoft Certification books I always hated. Today I found it very useful. After reading some pages, I could decipher what was on my screen. Yeah, I already install the administrative tools in English, but anyway, my Windows XP keeps on showing some messages in the OS language. The interesting thing is that you have basically three options to install apps:

  • Force user or computer to install a program, called assign by Microsoft, so it will install automatically at boot time.
  • Publish them in Active Directory, and make them available on Add or remove programs, in the control panel. I found this option very useful, because we can maintain there updated versions of all applications people can install but we don’t want to force them. In addition, I think is easy for the users to find what they want and click Install. You can add Categories and that way keep everything organized. And one app can belong to several Categories. Mola!
  • Ummm… I forgot about the third way. Oh, wait, you can also install programs if people click on an file whose extension is on the GPO. Still kind of a mystery for me.

Another amazing thing is that you can set all the Windows settings you want, and remove bad applications, like MSN Messenger or Outlook Express. Cool! I don’t know if I’ll have enough patience to wait until tomorrow to try it… In fact, I’m wondering why we are not using these features we’ve paid for. I should ask someone.

Resumiendo… Microsoft guys are not so bad after all. Despite bugs and headaches, I think Active Directory is one of the things they have succeed. In fact, they use open standards like Kerberos and LDAP. I believe that helps to integrate Windows with other systems, like my lovely Debian servers.

Tomorrow, I’ll continue my research. I still have a lot to read. Mainly the best practices section, but also the troubleshooting section, where they explain how to face their useless error messages. I hope there is some kind of “real” debug via the registry.

See ya! 😉

PD: to celebrate my discovery, today I prepared “Pinya ofegada amb panses i costella de porc” (cauliflower with raisins and pig rib). Delicious! 😀

Advertisements

2 Responses to Software Deployment via Group Policy

  1. Nick Allcroft says:

    Agreed, that’s a great feature of IntelliMirror technology. However, you have to pay attention to some specific and usually overlooked moments you encounter when dealing with software deployments. For example, it is not possible for a user to delete a computer-assigned application what makes ‘Assign’-type deployments a good selection for a mandatory deployments but doesn’t provide much of flexibility for a end-user to control the deployment process and configuration. Once more thing you should keep in mind when deploying software is that nowadays more tools use any kind of services that perform some functionality in background. What’ s more important here is that such services often contain a core functionality of deployed software. But the trickiest thing here is that you have to have administrative privileges in order to setup such service on a user computer. That’s were you usually get stuck. A I am saying that based on my own experience that may be different to yours. You have to keep your client computers locked down to prevent misuse and avoid security issues but you can’t handle everything at the same time relying only on basic tools. You either can lock the user from making inappropriate changes or allow him to setup and run such service-based software on your computer. For example, it’s a normal situation when you have to deploy a specific application to a specific user or group and then allow the user that user to run it only on a specified computer. Yes, we all do know about Microsoft LimitLogin 1.0 that allows to restrict login for a user to a specific computer and a runas tool allowing to run software under a different account with administrative privileges. When I used GPO Software deployments I did some assign deployments whereas some were made per-user using a ‘publish’ deployment method. The first one works best when you need to apply software at the Computer Configuration level deploying it prior to the user to log into his system. The last one is great to make a user-specific deployments.

    By the way since you are about deploying software I recommend that you enable Windows Installer logging http://support.microsoft.com/kb/223300 That would allow you troubleshoot deployment errors should this happen to you. You just have to define a Logging parameter of a registry string type within the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer key. The value name that will allow to enable a maximum level of details has a quite funny name: voicewarmupX. Remember also to learn Windows Installer options that you can vary using various msiexec switches http://support.microsoft.com/kb/227091 One of the interesting switches there is the /q switch with various extensions that allow running software deployments using the aforementioned publishing method quietly without interfering with user activities. Dealing with Windows Installer can be quite confusing. While it’s indisputably a marvelous technology that is a big leap forward from what we had before it requires you dig deep into specifics of using various switches and command extensions. For example that article that I’ve just mentioned here enumerates switches that can be used with msiexec. But not every administrator knows that Windows Installer also has properties http://support.microsoft.com/kb/230781 that extend its functionality and behavior during setup. For example you can define the REBOOT property and suppress or force the reboot of the computer while setting up software on the target computer. This can be useful when setting up such a huge application package as Microsoft Office http://support.microsoft.com/kb/826530 But as you might have noticed this article mentions a /noreboot switch that can be passed with a REALLYSUPPRESS property allowing you to prevent computer restart for every MSI package you pass to msiexec. You see that Application Deployment can be quite difficult to implement. The other thing is that it can be complex to maintain patch management and secure user computers by defining security limits for them. These are just a typical problems you may face with while deploying applications for the user. That was one of the main reasons when I started to search for an additional computer management software for our company. I’ve tried some solutions including the free ones like WSUS services http://www.microsoft.com/downloads/details.aspx?FamilyId=E4A868D7-A820-46A0-B4DB-ED6AA4A336D9&displaylang=en add-on for Windows Sever 2003 and found the third-party desktop management tool from Scriptlogic to be the most feature-packed and easy to use solution for my environment. Deployments there http://www.scriptlogic.com/desktop-authority-application-deployment.asp are really what you have under your thumb as you can control them with a maximum granular level. That’s one of those rare cases when the marketing hype just reflects the real situation. You realize that once you first come to deploy several different applications based on various options. For example sometimes my boss asks me to deploy some software of that user. I know we basically do not deploy this software to users but I am told that the user should have this software installed on his laptop computer because he needs this to run his presentation whatsoever. Now I need just to apply different software installation settings based on the computer type the user used to log into the domain. That’s quite difficult to do even when using a complicated scripting but that’s easy to do in Desktop Authority as I can define computer type directly when I setup deployment rule and switch between type if need make changes to the rule after the rule is prepared. All in all this Scriptlogic’s tool is a serious helper that greatly simplifies deployments. By the way, Scriptlogic has just released the new version 7.7 which has a very nice feature to deploy patches. Sometimes my users ask me to provide them with the ability to select if they want to reboot a computer or not because they need to end with their own task before the patch is applied. The new version as far as I know supports configuring user interaction right within the console without the need to modify MSI properties so that you can define whether the user can postpone the reboot and if he can just defer the patch deployment at all.

  2. Seppi says:

    “Resumiendo… Microsoft guys are not so bad after all” hereje, arderás en el infiernoooooooo!!!!!! Com va tot? ya veo que estás de fiesta todo el día, eh?! bergant!!!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: