Tagged group policy

If you administer Macs that are joined to an Active Directory, you either need to buy expensive Mac client-side extensions to apply Windows Group Policy, or you can extend your AD schema to include Mac attributes. Neither of these options are to be taken lightly, so when I needed to deny login for a particular group on our Active Directory (in this case alumni who no longer have access to on-campus computers), I wanted a simpler, scriptable solution. Thanks to our helpful software engineer at Apple, I was pointed in the direction of dsmemberutil, a command-line utility provided in OS X to determine group membership. Using that, I created the following script:

To make this work for any Active Directory group, just replace “alumni_only” with the name of your AD group. The kill line basically shuts down the loginwindow process and returns the user back to the login screen. I haven’t found a way to pop up a warning to the user when this happens, so I added in a message to be displayed at the login prompt.

Recently at work, I had to come up with a way to uninstall any installed versions of Java on our AD managed systems, then install versions 1.5.11 and 1.4.2.12 (the latest versions of 1.5 and 1.4, essentially). Luckily, Alan found a site that directly addresses this issue, and I was able to quickly grab all the upgrade codes for the previous Java MSIs. Armed with this info, I quickly inserted all the upgrade codes into the 1.5.11 JRE MSI, which I had extracted from the setup .exe bootstraper (it’s in %username%\Local Settings\Application Data\Sun\Java\jre1.5.0_11). I tested it with 1.5.10 on my system, and it upgraded it like a charm.

Since the upgrade code for each sub-version is different (why, Sun, why?), you have to paste about 20 codes in one by one, which is a major pain. As a service, I’ve created an MSI that is only the upgrade codes. Just paste the upgrade table of this MSI into the Sun Java one (I’m not providing a hacked MSI on this site, that would just be stupid), and you’re good to go, and you can avoid the 20 stupid table entries. Here’s the file:
[download#7#image]

Windows Server 2003 offers systems administrators a new* and exciting tool for deploying applications across the domain: MSI deployment with Group Policy using Active Directory. Basically, if you can turn any app setup into an MSI, you can easily push it to any and all machines on your domain through Group Policy. Using the silent flag for msiexec, you can make these installs completely automatic, with no user interaction whatsoever. When your user boots up the machine, there is a slight delay while the MSI installs, advertised by a small dialog box in the top left corner, which indicates what app is being installed. After the install is complete, the user will be logged in completely normally, with the new app available to them. For a detailed walkthrough on deploying your app through Group Policy, click here. You can also read the Microsoft documentation here.

If you’ve worked with MSIs before, you’re aware that you can either stream setup files with the MSI directly, or attach them separately in .cab cabinet files to be extracted at run-time. The former method saves file space: when the user installs the program, only the MSI is cached in WINDOWS\Installer, so the data in the cabinet does not occupy space on the user’s hard drive. The downside, of course, is that you can no longer get clean copies of those files during a re-install unless you have the original installation media. The other major downside, from an Active Directory standpoint, is that you can only push single MSIs with Group Policy, not multi-file installs.
So, if you have an MSI with a separate .cab file, what’s the easiest way to stream that cabinet? First you’ll need the Windows Installer SDK (available separately from the 1.2Gb Microsoft Platform SDK as a 7.9Mb download here). In there is a program called msidb.exe. Its only mission in life is to pack .cabs into .msis, so it’s appropriate for the task. If you’re into esoteric stuff like that, you can check out the full docs here.

1) Put the .cab and the .msi in the same directory as msidb.exe.
2) Open a DOS prompt and navigate to the directory with msidb.exe in it.
3) Run the following command, replacing the defaults with the names of your MSI and CAB files “Msidb.exe -d mydatabase.msi -a mycab.cab”
4) In the Media table of your MSI, rename the link to the .cab file with a # sign in front of it. In other words, if your file is called Data1.cab, the Cabinet column of the Media table should now read #Data1.cab.

Your MSI will now look inward to find the files it needs, and after all, isn’t that what world peace is all about?