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.
The time has finally come for the Free and Pro versions of PDQ Deploy to be merged. We've been working on getting a single version of PDQ Deploy to match the single version of PDQ Inventory and we're nearly there. This first public beta of PDQ Deploy 1.5 takes us one step closer.
Merging Free and Pro into one product has a number of advantages, not the least of which is the simplification of the development process leading to faster releases of new features. Free users will get the benefits of new features from Pro without waiting and Pro users will get new features faster as we streamline development.
So, what else is new in 1.5? Here's a rundown.
- New data grids supporting printing and exporting to various file formats and other useful features.
- Import from and link to groups in Spiceworks.
- Deployment service. This is new for Free users, now deployments run in a background service allowing the console to be closed while deployments continue running.
- Copy and paste actions from one installer to another.
- Import/Export schedules.
- Improved interaction with the PDQ Deploy service to fix issues with credenditals.
- Many other bug fixes and enhancements.
Beta 2 will include a bunch of new user requested features, so keep an eye out.
Feel ready to give it a go? Download the beta from here and sign up for e-mail updates when new versions are available.
It's effectively removed two weeks from our lives, but lo and behold our office move has been completed.
All of our servers are starting to get reconnected so that we can start making more how-to vids and provide support.
Man it's been frustrating having all of our ESXi servers powered down and waiting for the last little while. But they are (almost) all running now as is evidenced by the fact that Shane is making vids as I write this.
It's not perfect quite yet. We still don't have our broadband yet, so we're stuck with the backup solution of using my Sprint 4G WiFi card. But hey, it works.
Anyway, we're not going to change our mailing address (please continue to use the PO Box). But our new address is 230 W. 200 So. Suite 3101 Salt Lake City, Utah 84101. It's nice be downtown again, a simple walk from some great restaurants, pubs, and hang outs.
Broadband will be installed next week. After that we'll pop the corks and get back to work.
Thanks for hangin' with us.
We're pleased to announce the second beta release of PDQ Inventory 1.0.1. It's available now for download now.
This beta focuses mainly on bug fixes but there are a couple of small new features.
- When the console starts it will check the PDQ Inventory's credentials and make sure that they are set correctly, restarting the service if needed.
- Added a desription to collections. The description shows up in the header on the collection page.
- Renamed the Scan Date column on computers to Attempted Scan Date to better reflect the value. The next beta will include Successful Scan Date which will contain the date of the last successful scan.
- Added collection filters for Local Users, Local Groups, Local Group Members, and Shares.
The big new feature, however is SQL Reports. Now there are 2 types of report: Basic, using the report builder, and SQL which allows for reports to be created using any valid SQL. Please give it a try and let us know what you think.
Our next scheduled beta will be Beta 2 of PDQ Deploy and Deploy Pro. This beta is taking a bit longer because of one large change. This new version will combine PDQ Deploy and PDQ Deploy Pro into one product. It will work like PDQ Inventory in that it will have a Free and Pro mode. We're going to use the PDQ Deploy product name and it will actually be released as version 1.5.0 (Beta 1).
It's taking some more time to test because the software needs to upgrade both PDQ Deploy and PDQ Deploy Pro. Since it's using the PDQ Deploy name it will install over PDQ Deploy and along side PDQ Deploy Pro, so that you can still run PDQ Deploy Pro while testing PDQ Deploy 1.5.
Thanks again for all of your help with testing the betas.
Download PDQ Inventory 1.0.1 (Beta 2)
Sign up to receive e-mail notifications of new updates
Photo by Chris Devers
Attention passengers, boarding will begin momentarily for the maiden voyage of Apple flight 101. You may notice that no pilot has entered the aircraft. We're pleased to inform you that for safety reasons, no human will be allowed to enter the cockpit. Rest assured, however, as our experienced pilots will be flying the aircraft via Apple Remote Desktop right from their comfortable lounge seats here at Cupertino Int'l airport.
Now boarding zone 1.
Slashdot reports that Apple will be requiring Mac App Store submissions to work within the sandbox.
To calm my fear that Apple would lock down OSX, shortly after the iPad was released I remember stating to friends "if Apple believed that locking down the iOS was so good they'd also do it with OSX".
I really hate the taste of crow.
Before I move any further, in the interest of providing two sides to what I consider a one-sided story, here is an article from CNET where Topher Kessler puts a happy face to this move.
In June 2010 I had a brief conversation with Jason Calacanis (TWIST host during a meetup.com special) when he asked me if I thought that Apple would start to make headway in the corporate arena.
Jason: "In the enterprise are people moving away from Windows, are Apple and Macs starting to get some foothold or is that something that MacHeads like to think?"
Shawn: "Not in the Enterprise... In some of the niche markets like art studios you'll see a lot of Macs. I use a Mac for personal use but I make money on Windows [because] that's just what companies are using."
Jason: "So what do you think in the next five, ten years, do you think you'll see Apple starting to take market share in the enterprise?"
Shawn: "[yes, but only] if you can integrate them with Windows a little better..."
My reference to "integrate them" was a direct shot to the iPad. It's almost impossible to manage that device at the enterprise level. That's because vendors like my company, Admin Arsenal, are severely limited in our ability to provide the same level of management for the iPad that we provide for our Windows customers. The move to make OSX more like iOS means that we likely will not be developing our technology to manage something that Apple is determined will not be managed by 3rd parties.
Sorry folks. Just like we would be hesitant to fly in a plane with no pilot in the cockpit, so too are we hesitant to develop applications for a platform that we can't actually access.
The folks at Redmond have probably ordered the caterers and bartenders for the upcoming party. They still own the business market and will continue to do so until an enterprise management solution for Macs and iPads is available.
Businesses track computer assets differently than do households. Because IT is such a large expense category in the professional world, it only makes sense that assets be managed. By managed I mean...well... managed. You can't get an accurate hardware inventory without talking to (go figure) the hardware. To manage a system you must be able to both install and uninstall applications without actually touching the device or otherwise disturbing the user. (I could go on and on, but you get the point).
Here is my prediction. If Apple wants the business market, they can only get it by providing systems management solutions for their platforms. If they prevent the solutions from being developed by 3rd parties, then from Apple itself will develop them. True they have Apple Remote Desktop, but any solution will need to integrate well with Active Directory environments (sorry, but that's just reality).
To that end, I predict that Apple will release their own enterprise management suite (iManage, anyone?) that will allow you to use their software to manage enterprise installations of Mac OSX and iOS devices. Since they don't have to eat the same dog food as their developers they will have access to private API's and have the ability (short-term and long-term) to leave the sandbox and talk directly to OSX and iOS hardware, processes, and other applications.
This future systems management applicaton will be functional, beautiful, and very expensive.
True, recent history has taught us that if a hi-jacker gets into a cockpit bad things happen. But the solution is to lock the cockpit door, not weld it shut.
Just ask the 100,000+ iOS and OSX pilot... I mean developers.