One of the first things that most Sys Admins like to do after they deploy Java is to disable the automatic upgrade check. The last thing a sys admin wants is to receive hundreds of calls all asking the same question "I have a window saying that there is a...one minute... Java J-R-E update. Do I have a virus?"
Using PDQ Inventory you can send a remote command to turn off the automatic upgrade check. If you have the Pro mode of PDQ Inventory enabled you can also verify all the systems that do or don't have this setting applied.
The following video shows the steps needed to nail this down. In the first step we create a dynamic collection to display which systems have Java version 6.
Follow along in your own environments and you will get a good idea of how PDQ Inventory can help you get control of your computers.
Warmer...warmer...hotter...oh, colder. Sorry.
PDQ Deploy is an excellent tool for not only deploying software but also "deploying" changes to target computers such as: Registry modifications, copying files or just running commands. There are a few gotcha's, however.
We recently had a question that basically looked like this:
Hi Guys, I am able to locally change a registry via a reg file but when I deploy the change with PDQ Deploy it doesn't make the change. Why? Here is a snippet of the reg file...
One glance at the registry file told us why he was having a problem. The reg file was writing to HKEY_CURRENT_USER. In actuality, the deployment was working. The registry was being modifed it was just changing the HKEY_CURRENT_USER value for a different user than the administrator thought.
First of all, what is HKEY_CURRENT_USER? This is the registry hive which holds keys and values that are respective only the current user. Its values are contained in the hidden file NTUSER.DAT located in the root of the user's profile directory. Anytime a profile is created on a computer (basically when a user logs on to a computer for the first time) this file is generated and loaded into the registry. When the user logs off, the hive is unmounted.
Let's say that the user Tony is currently logged on to the machine Accounting12. When Tony logs on, any startup script or user level GPO that references HKEY_CURRENT_USER is referencing the NTUSER.DAT for Tony.
Now let's say that you are running PDQ Deploy version 1.5 (currently in a public Beta). The account (credentials) that you are using to deploy software is your Administrative account, Dorene_Admin. You are deploying some registry changes by importing a .reg file called CompanyRegistryChanges.REG.
Dorene_Admin deploys the PDQ Deploy Installer to the computer Accounting12. After PDQ Deploy finds Accounting12 it creates a Windows Service called AdminArsenalRunnerService that loads the installer and begins executing the defined Actions (PDQ Deploy Pro Mode has the ability to run multiple Actions in sequence whereas PDQ Deploy Free Mode can run only one action per installer). But guess what? All the registry changes that affect HKEY_CURRENT_USER are being made against the NTUSER.DAT in...wait for it... the profile for Dorene_Admin. Why? Because according to the regedit.exe process (which is being called to import the registry file) the current user is Dorene_Admin. This is because regedit.exe was executed by the Dorene_Admin account therefore all "user" actions (such as HKEY_CURRENT_USER) or even referencing the variable %UserProfile% will all reference Dorene_Admin.
So basically when I need to make changes to the HKEY_CURRENT_USER in the registry or the %USERPROFILE% directory I try and utilize User Level GPO's. You can, of course, write a script that traverses all the profiles on a target and then loads each NTUSER.DAT and make the changes there but I generally discourage that. It can be done and I have, myself, done this when a GPO wasn't possible.
A good rule to remember is that PDQ Deploy is primarily meant to deploy changes (Software, Registry settings, commands) to a computer and not to specific users of a computer. Registry changes to HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT and HKEY_USERS are slam dunks.
Hey System Administrators! One of the many cool features in the Pro mode of PDQ Inventory is the Registry Scan Profile. With this scan profile you can define certain registry keys that you want to scan on all of your computers and then store the results in your PDQ Inventory database.
What if you want to know if a certain process is set to start at logon time? Scan the Run and RunOnce keys. Check out this quick video on performing this task with PDQ Inventory.
What if you want to see if the Remote Administration firewall setting has been enabled? Or, more specifically, what if you want to find all the computers in your environment where Remote Administration is not specifically enabled? Here is an example where we use a new Scan Profile to find the problem computers.
Do you really need a Java MST?
There was a bit of discussion after my earlier post about installing Java 1.6 update 25
. The question came up about TRANSFORMS with Java. Users have reported that using the provided sp1033.mst from Java (Oracle) was taking up to 5 mins longer to do an installation.
I took a look inside the sp1033.mst and there is very little that I would change (and by very little I mean nothing at all). Most of the changes come in the profile section, which can be set during installation with an MSI parameter (/SYSTRAY=0 /JAVAUPDATE=0, etc.). That being said, I'm not really sure what the value is to even calling the MST. It seems to me that only using the actual msi and data1.cab are just fine. The defaults from Java are installed, and you can overwrite quite abit with MSI parameters if you feel the need. I haven't seen any negative effects from only copying the data1.cab and MSI and using those for your installation.
If you find that you need to make some custom registry changes you can do so in a batch file or if you are using PDQ Deploy Pro, you can have multiple actions in your installers. These actions can be commands or other installers. Choose command. Here's an example of making a reg add/change with an action in PDQ Deploy Pro.
Action 1 is the installation (calling the MSI):
Action 2 is a reg change:
Unless you know what each column in the MST is, I would recommend against making changes. Unfortunately I've not been able to find any published info from Oracle on the subject of the JRE provided MST's.
One thing that I have discovered is that change is constant at Oracle. MSI profiles (parameters) are deprecated from earlier versions of Java (for instance IEXPLORER=1 MOZILLA=1). Registry paths are changed, so if you blanket use a reg value from an earlier installation script for Java you may create that key, but it won't be doing what you think it is.
Lesson? BE WARY of using parameters from earlier versions of Java updates. They have changed from update 22 to 23 and 24 to 25.
Lastly, I've learned that very few forums are buzzing about Java update 25 right now. I get the distinct impression that there are many sys admins who are simply waiting on pushing it out.
On the discussion that using the provided sp1033.mst is taking longer; that may well be the case though I wasn't able to replicate that behavior in our lab. My Java installations using PDQ Deploy consistently came in around 1 minute (sometimes faster). Still, if you're not changing any values in the MST I don't see a need to even include it during the push. Just be certain that your msi and data1.cab file are ready for pushing and you should be OK.
If you have experience with the Java 1.6 update 25 MST and you feel confident that it's valuable to make changes (that can't be made during installation via paramters) then PLEASE shoot us the MST and let us know what changes you made. We'd love to see what can be done to make this a clean install for folks.
Photo by Mr Thinktank
After many years of digging through the Windows Registry for various purposes, unbelievably not all of them purely masochistic, I have discovered a few keys that are amazingly well hidden. So well hidden, in fact, that many would claim that they don't exist. Ignore those people, they are just agents of the Triluminati Council on Bilderberg-Bohemian Relations and they want to keep these keys to themselves.
To see these keys you need a special version of Regedit.exe. I would point you to a download for it, but if I did it would be immediately removed by the powers that be. You may be able to get a copy from the Time Cube guy.
Hold on to your mad hats as we see how deep this rabbit hole goes.
This key enables the quantum components of your processor allowing you to decrypt everything like in that movie Sneakers. Normally only the NSA and Proctor and Gamble have access to this key.
This is where the most recent scan of your brain taken by your flat screen monitor is stored. This scan can be avoided by either wearing a tinfoil hat or by going back to a giant CRT monitor. The tinfoil hat would be less embarrassing, though.
Depending on where you bought your computer one or more items like these will be present. In typical government intelligence fashion, it appears that they don't follow the Windows development guidelines and store things that should never go in the registry. PGP backdoor decryption code should always go in .dll files.
Same as above, but only on really old computers.
Stored here are little bits and pieces of alien software which blue screened on your computer in the distant past. Shortly after initially displaying the contents of the key the system will rename it Crash\WeatherBalloon. Don't be fooled.
This key actually holds the real registry used by your computer, and it's very different than the "official" registry you've been told about. Apparently all blue screens, freezes, and odd behavior are coming from the system. Do you really think that a handful of hardware driver writers are capable of pulling it off? I don't think so.
If you see this key then you have been programmed as a sleeper assassin. Delete it immediately!
Set this key to DWORD 1 in order to prevent being Rick Rolled, as detailed in this tutorial.
Photo by quacktaculous
After a standard 22 hour shift of remote software deployment, getting medieval on UAC and completely wrecking the registry many System Administrators kind of create their own scent. If only Ralph Lauren could isolate the chemicals that our IT bretheren and sisters produce, an entirely new line of perfumes and colognes would spew forth. Here are a few potential products that come to mind as I recall the aromas of cluttered cubes and server rooms in my past:
- WMI Access Denied Mist - A rich blend of Green Monster and Cheetos. This cologne is known to leave an orange residue on your fingers and, subsequently, on your keyboard as you try and figure out the damn WMI security.
- Essence of Registry - Get lost in the blend of Outlaw Beef Jerky and Room Temperature black coffee (Folgers, of course).
- Infinity by Loop - This is the scent that, like that recursive sub-routine you wrote this morning, will never, ever end. The ingredients are a hodge-podge of Mongolian BBQ mixed with some Kimchee your co-worker swore that you'd love.
- Gamer by Gaultier - Oh yes, the cologne of gamers: Forget old-school BO and flatulence we now have Pizza Pockets and Natty (or whatever else your roommate has to drink in his fridge). Mix these ingredients with 3 day old skid marks and navel lint that the EPA now considers an official marsh and you have the perfect essence of the notorious Sys Admin Gamer.
- Hommes Taches de Traspiration (Men's Perspiration Stains) - This French cologne will ensure your legacy as the go-to-guy for all things BASH.
- Stallman by Richard Stallman (self-explanatory)
- LDAP by FCUK - The French Connection finally came through with a perfume that the ladies will love. Spritz this little joy on you at your next Microsoft Tech-Ed appearance and watch the booth babes weeping from loneliness as you run to the nearly deserted Women's restrooms to plan your ultimate exit strategy.
- UAC by Morgoth - This is the first cologne whose active ingredient is profanity. Trying to get that code to run as a service under UAC? This is actually a good starting point to play the Windows System Administrator Drinking Game. Mix in a 5th of Jack, some office violence and you have, UAC by Morgoth.
- Chamber of Halitosis by Tom Ford - Mix that 22 hour shift with in-N-out burgers, Cartesian Joins, chronic gingivitis and 7 straight years of abstinence and you have the ultimate Sys Admin aroma. Free, at no extra charge, you will avoid promotions into management, mandatory meeting attendance and, indeed, all human contact.
Remotely deploy your apps with a free trial of Admin Arsenal
and cut down that 22 hour shift to a manageable 16.
Subscribe to the Admin Arsenal blog for all of your technical non-hygiene enhancing needs.
A common problem that users encounter when using agentless tools to manage their computers is that they have the RemoteRegistry disabled.
Since Admin Arsenal is one of these agentless tools, RemoteRegistry must be enabled in order to perform many essential Windows Administrator tasks.
After enabling RemoteRegistry you'll be able to see what software is installed on your computers.
Admin Arsenal runs five tests on each system to ensure that is has the necessary settings and privileges to allow you to manage efficiently.
- DNS Lookup
- ADMIN$ Share
Have questions? Visit our forum at support.adminarsenal.com for answers to common questions.
Follow me at Twitter @ShawnAndersonRolling out software
? Do it for free with our 30-day fully functional trial.
Photo by Steve Snodgrass
Here's a (seemingly) random collection of registry settings which I have recently encountered that you may find useful. Hopefully there's one or more that you may not be aware of.
1. Enable Unsolicited Remote Assist
Unsolicited remote assist is very handy for troubleshooting problems on a remote computer where you don't have some other form of remote control such as VNC. I've found that enabling it through the UI doesn't always allow it to work, and you get some cryptic errors. These settings seem to really get it going.
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
fAllowUnsolicited = 1
fAllowUnsolicitedFullControl = 1
AllowTSConnections = 1
fDenyTSConnections = 0
fAllowToGetHelp = 1
2. Increase Desktop Heap
Sometimes opening a lot of windows or tabs in Internet Explorer pushes use of the heap (a section of memory used by the desktop.) When you bump up against the limit, strange things start to happen. This blog post details a way to increase it which gives you more headroom.
3. Allow Popups on Secure Sites
Internet Explorer's popup blocker is pretty handy most of the time. But when you're connected to a secure web site you may want it disabled because the popups are part of the user interface for the site (such as for authentication.) This setting allows popups on HTTPS sites.
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\New Windows
Allow HTTPS = 1
4. No LAN Manager Hashes
An oldie, but a goodie. This entry prevents the system from storing LAN Manager password hashes which are much less secure than Kerberos or NT hashes. Older systems such as Win 98 and ME won't be able to authenticate, but that's actually a benefit.
NoLMHash = 1
5. Disable Shaking
This one is a personal taste thing. I don't like the shaking
feature of Aero in Windows 7, I seem to activate it all the time on accident (perhaps I have muscle spasms.) Here's a way to disable it.
HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ Advanced
DisallowShaking = 1
6. Screen Saver Grace Period
The default setting for the grace period on requiring a password after the screen saver starts may be a bit too short for you.
ScreenSaverGracePeriod = (number of seconds)
7. Take Ownership Menu
This one isn't as much of a registry setting as it is a shortcut, but it's still handy. If you find yourself needing to take ownership of files a lot, this will be quicker than going through the security tab. It adds a menu item in Windows Explorer when you right click on a file or directory which will give you ownership.
(default) = "Take Ownership"
NoWorkingDirectory = (empty)
(default) = "cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
IsolatedCommand = "cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
(default) = "Take Ownership"
NoWorkingDirectory = (empty)
(default) = "cmd.exe /c takeown /f \"%1\" /r /d y && icacls \"%1\" /grant administrators:F /t"
IsolatedCommand = "cmd.exe /c takeown /f \"%1\" /r /d y && icacls \"%1\" /grant administrators:F /t"
8. Disable Simple File Sharing
Simple file sharing in XP makes remote administration a bit difficult, mainly by disabling the admin shares (ADMIN$, C$, D$, etc.)
forceguest = 0
9. Disable Writing to USB Drives
This is a helpful security setting if your organization wants to disable writing to USB drives on certain machines.
WriteProtect = 1
10. Default User Settings
This is more of a tip than a setting. If you need to restore a key in HKEY_CURRENT_USER to its default, you can find them all in HKEY_USERS\.DEFAULT. This is also handy if you want to change a setting that will be used for all new user accounts because it is used as a template for each new user's registry settings.
Get a free 30-day trial of Admin Arsenal
and distribute registry changes with just a few clicks.