Today I realized I needed to get the Remote Server Adminstration Tools (RSAT) installed on some computers. I realized that I should have just created a PDQ Deploy installer for this a long time ago. I wanted to know what all the feature names for RSAT were so that I could build my installer. I went on a nice leisurely stroll through the Optional Windows Components whilst cranking Motörhead. I initially thought, "hey, I'll use OCSetup to enable these". OCSetup worked but not every time. I decided to move over to Dism. I don't want or need every tool that is included in RSAT (which is probably why Microsoft didn't enable them out the gate).
To see what Windows Components you have installed on your computer (whether or not these components are enabled or disabled) run this command:
Dism /online /Get-Features
The /online switch tells Dism that it will be working with the running (or online) Operating System.
To enable a feature in Dism, you simply run:
Dism /online /Enable-Feature /FeatureName:<name of feature>
To be able to manage your DNS servers using the RSAT DNS component you would run:
Dism /online /Enable-Feature /FeatureName:Dism /online /Enable-Feature /FeatureName:RemoteServerAdministrationTools-Roles-DNS
You can feed an answer file to Dism to enable or disable many features but I only needed a handful so I just used the ability in PDQ Deploy Pro to run some commands after RSAT was installed. (See snapshot of my RSAT PDQ Deploy Installer below)
You can see how I have multiple Actions defined after the initial action of installing RSAT.
Unattended installation of WinZip? Check. Quiet deployment of VLC? Yep. Free Software deployment? Damn straight. Free Inventory? To quote Kip from Napoleon Dynamite: "That's what I'm talkin' about"
Hey Windows Administrators, hit up our forums at http://support.adminarsenal.com/forums.
UPDATE: 14 Nov 2012 - This error (1602, User Cancelled Installation) is still occuring in Adobe Reader XI. PDQ Deploy Pro mode users can create a first step in the deployment to kill all Reader processes before proceding with the installation.
It sounds like something out of a 'B' grade horror movie. You're deploying Adobe Reader X silently which, it hardly needs stating, means that your users aren't aware of the push.
You suddenly see a failed distribution with the error "User cancelled installation".
A quick flash back. The year was 1998. We had just setup a T1 (I know, I know) for our office. On top of that Adam had a most coveted home DSL connection. With his new 128 KB connection we decided to setup a VPN to our office so that Mr. Ruth could work remotely. It was shortly after this period that I was at the office working late. Alone. All of a sudden the silence of the office was shattered by our main printer as it started shooting out a large print job.
After using our inner-office defibrillator on myself, I quickly realized that it was just Adam working from home.
These two stories share something in common. They were both unexpected and ever so slightly disconcerting.
Back to the Reader X deployment. This happened to one of our users this week when using PDQ Deploy to install Adobe Reader X.
The situation, discovered through logging the installation, was that Adobe Reader 8 was currently running on the target machine and had locked files. The Adobe installer decided that throwing an error 1602 (User cancelled installation) was an appropriate error code (we humbly disagree).
Again, logging saved the day. Here's a quick refresher on logging installations when pushing out an MSI.
To enable logging add /log <file-name> to the command-line options. Be sure to include the full path to the log file because the installer directory gets deleted at the end of the install taking any log file in the same directory with it.
The logging output showed the following:
ADelRCP logging: : In Process : AcroRd32.exe
ADelRCP logging: : AppsInUseEx targeted module is in use: C:\Program Files\Adobe\Reader 8.0\Reader\AcroRd32.dll
ADelRCP logging: : Setup terminated because critical files are in use or applications that interfere with files installed by setup are running. Review the preceding entries in the log file and close the applications listed before retrying setup.
Action ended 14:14:58: ApplicationsInUse. Return value 2.
Action ended 14:14:58: INSTALL. Return value 2.
Solution. Wait for the user to end his or her Adobe Reader session and restart the push.
Thanks to our users Jonathan, Amanda and Jason who each discovered this nice quirk with pushing out Reader X.
Yeahhhhh, I'll go ahead and send you that memo, one more time.
A natural and fully expected question that we have been hearing goes something like this: "What are the differences between PDQ Inventory and my current AA Console?"
We'll start with some major differences.(note, some features exist only in the Pro enabled version of PDQ Inventory)
- File Scanner - PDQ Inventory Pro enables you to define directories and file types that you want scanned. If you want to keep tabs on all of your .exe files that exist under C:\Program Files then you simply create a new Scan Profile and define the path and file type. Voila! A file scanner tracks file dates, size, name and all the header information (version, company, etc)
- Registry Scanner - Already discussed in some earlier posts. Basically, you can collect registry configuration settings by defining different Registry paths that you want scanned
- No more reliance on remote WMI connection - This was a big decision for us. AA Console depends on being able to access the WMI repository on all target systems via DCOM. There were a lot of hurdles to get through to properly configure this ability to access WMI remotely. Note, while PDQ Inventory still references the WMI repository to obtain certain inventory data (such as O/S, Windows Shares, etc) it does not, like AA Console, have to get it remotely via DCOM.
- Improved database. AA Console utilizes Microsoft SQL Server CE (Compact Edition). This version of SQL is very prone to corruption and is rather difficult to access via other SQL reporting tools. PDQ Inventory utilizes SQLite which is not nearly as prone to corruption, can be easily accessed via ODBC and is simply more scalable than SQL CE. (See Adam's previous post about access the PDQ Inventory DB via Microsoft Access)
- No longer reliant on Active Directory. In AA Console all managed computers had to be a member of an Active Directory domain. With PDQ Inventory that is no longer the case.
- Scan Profiles - with AA Console you effectively had two types of scanners. One for heartbeat (was the computer online, who was logged on, etc) and the other for, well, everything else. With PDQ Inventory you can break your inventory scanners down to very specific elements. Suppose you want to scan the Environment variables all of your target computers every hour but you only wanted to scan for Windows Shares every week. With PDQ Inventory Pro you can easily do this.
Obviously the ability to deploy software is contained in the PDQ Deploy application. PDQ Inventory and PDQ Deploy are separate products but can be integrated to leverage each other's strengths. For example you can deploy software from PDQ Deploy via PDQ Inventory.
One feature in AA Console that is not available in PDQ Deploy or PDQ Inventory is Monitoring. We are discussing providing a monitoring tool outside of AA Console but we have not, at this writing, made a decision.
Our public beta
of PDQ Inventory Pro is winding down. Thank you to all of you who have submitted feature requests, bug reports, complaints and thinly-veiled death threats.
Keep the feedback coming in...especially any bugs that you encounter.
Windows 8 could bring tablets to business
Hats off to the folks in Redmond for making Windows 8 exciting to read about.
As seen on slashdot, PCPro discussed some of Microsoft's plans for the upcoming Windows 8 release, and it looks cool.
- Same interface for both touch and traditional screens
- Windows Desktop "effectively demoted to an app"
- App store
- Syncing apps across all Win8 devices
While it's obvious to see the consumer appeal here, it will be interesting to see how businesses respond. I rarely find myself saying this but if Microsoft can make their Metro Style Apps work well in business settings (meaning centralized management) then they will beat Apple to the punch.
OK, disclaimer time. Regular readers of this blog will know a few things. 1) We make Windows software, 2) everyone in our company uses a Mac, and 3) we love both. (I'm writing this blog on my MacBook Air with my trusty iPad2 and Android next to me.)
With the disclaimers out of the way, I can now say that the GAPING hole in the iPad arsenal is the lack of centralized management. I'm really excited to see what Microsoft comes up with. So far (let's be honest everyone) Microsoft is copying Apple's approach to tablet computing and app stores. But Microsoft can take the lead with business.
Allow businesses to track their tablet hardware like they do with their servers and workstations.
Back in January I wrote the following blog on a story about the number of XP OS's still in use:
"I'm beginning to wonder if Win7 will surpass 50% by the time Windows 8 goes to Release Candidate. I'm still hoping to see a huge advantage to Windows 8 - the feature I just can't live without. At this point I wouldn't even care if it came from Cupertino first - just give us something awesome."
C'mon Redmond, we've been waiting a long time to see you announce something super cool... please don't let this be another Vista.
In AA Console we added an export to Microsoft Access feature to make the database available outside of the application for reporting and other purposes. This was done as a workaround to the fact that there isn't an easy way to get to a Microsoft SQL Server CE database from external tools (no ODBC driver, in particular). Our newer products (PDQ Deploy Pro and PDQ Inventory) use SQLite instead, and this is one of the reasons. There are many tools out there to use SQLite including ODBC drivers which will allow for Microsoft Access to directly connect to the database, but it does take a bit of configuration. This quick how-to guides you through the process.
Step 1 - Download and Install the ODBC Driver
The most popular ODBC driver is an open source one kindly created and provided by a developer named Christian Werner. You can download it from his website. Grab the 32 or 64 bit version, as you need, and install. It's very quick and will add itself to the list of available drivers in the ODBC control panel.
Step 2 - Configure a Data Source
Open the ODBC Data Source Administrator tool from the control panel.
Decide whether to create a data source as User, Machine, or File. The only difference between the three is who can use them. User for only the current user, Machine for all users on the machine, and File for anyone who has the file given to them (even on different computers as long as the driver is installed). We'll use User for this how-to.
Click the Add... button and select SQLite 3 ODBC Driver.
Next, fill in the database information. You only need the Data Source Name and Database Name, you can leave everything else default if you're only looking to read the database for reporting purposes.
The database name for PDQ Inventory is %ProgramData%\Admin Arsenal\PDQ Inventory\Database.db where %ProgramData% is either C:\ProgramData or C:\Documents and Settings\All Users\Application Data, depending on the version of Windows. PDQ Deploy Pro uses the same location with, surprise surprise, PDQ Deploy Pro in place of PDQ Inventory.
The ODBC source is now ready to be used by your favourite reporting tool. I'll show you how to use Microsoft Access 2010 (the process is very similar for earlier versions).
Step 3 - Link to Microsoft Access 2010
Microsoft Access has two ways to use external data, either import or link. Import, as the name implies, is a one time import of data which works well if want the data as Microsoft Access tables and don't care about future chages (though you can re-import). Linked tables always access the most current version of the data from the database and is probably what you want for reporting purposes and the method I'll describe.
Create a new database or open an existing one and click the ODBC Database button on the External Data tab.
In the Get External Data wizard, select Link to the data source by creating a linked table.
Select the data source you created in Step 2.
Then select the tables you want to link. If you know the tables you want, just select them, otherwise select all if you want to explore the data.
You may be prompted to Select Unique Record Identifier for some of the tables. This is because some of the tables, for various technical reasons, don't have a unique key defined. You can just click OK on those tables as the unique key is only needed if you're going to be updating the data, not if you're only going to be running reports.
That's it! You now have direct access to the data for reporting and other nefarious purposes. At the present time we don't document the structure of the data, but hopefully the tables and columns are named well enough that you can get just what you want.
As always, if you have any questions or concerns just post them on our forums and we'll help you as best we can.
You can suppress or prevent a reboot on Office 2010 using the Office Customization Tool (OCT)
In a perfect world the settings would all be listed in the OCT, but since that isn't the case, we'll list some here.
From the Modify Setup properties you select Add and enter the following Name:
and its Value:
Suppressing the reboot will be helpful to your users, but eventually (as soon as possible) you should initiate a reboot. You should do the reboot before any Office 2010 security patches are installed.
Here are some more Office 2010 properties that can be changed via the OCT. That page also lists some of the older, or blocked, properties from earlier Office installations (pre-2007). Here is a quick list of what you can modify in the OCT for Office 2010.
The following properties can be used when you install Office 2010 (and the 2007 Office system):
- HIDEUPDATEUI – If set to True, hides the Check for Updates button on the completion dialog box. This property is ignored if the completion dialog box is not displayed. The default value is False.
- PRIMARYFOLDER – Designates a primary folder for the installation.
- ROOTDRIVE – Specifies the default drive for the destination folder of the installation. The value for this property must end with '\'.
- SETUP_REBOOT – Determines how Setup restarts the computer after installation. You must use all uppercase letters, SETUP_REBOOT.
- AutoAlways – Always initiate a restart. Do not prompt the user.
- Always – Always prompt for a restart at the end of Setup.
- IfNeeded – Prompt for a restart at the end of Setup, if Setup requires a restart. (Default)
- AutoIfNeeded – Initiate a restart, if Setup requires a restart. Do not prompt the user.
- Never – Never initiate or prompt for a restart.
Need to deploy Office 2010 to all your company computers? Try PDQ Deploy. It's free to use.
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.