Install Shockwave silently (and then fume over the results)

Uncategorized

Adobe Shockwave (formerly Macromedia) is one of those applications that most users know about by visiting a website that asks them to install or update.

We believe that users should not have to install applications (or updates) themselves (they are, afterall, users). Here is a quick way to push out Adobe Shockwave to all your computers, quickly and silently.

Like all free Adobe products, you need to submit a distribution agreement to be able to distribute Shockwave. It’s still el-free-bo, but you need to submit the forms. Each agreement is good for one year.

After approval (it can take a day or two) Adobe will provide a download link for you. The file name (as of this writing) is:

sw_lic_full_installer.msi

Open PDQ Deploy (it’s free) and create a new installer for Shockwave.

install shockwave silently 01 resized 600

Let’s create a deployment so that we can choose our targets. Click “Create Deployment”.

install shockwave (formerly Macromedia) silently

After your targets have been selected verify that there are green checkmarks next to their names. This lets you know that the hostnames are in DNS (it does not mean that they are online, however).

If you need to change the account that you will be installing shockwave under you can do this by selecting “Next Step”, or if you are ready to deploy you can simply select “Deploy Now”.

install shockwave using pdq deploy

Shockwave is now installed. If you’re happy with the default behavior that ships with Shockwave (i.e. auto-update checking, sending anonymous usage, etc.) then you’re done.

If you are wanting to disable Auto-update then you’ve got a little more work ahead of you.

Unlike Adobe Reader, Adobe hasn’t provided a Customization Wizard for Shockwave. So if you want to make some of these changes you’ll need to do some tinkering.

(You probably won’t be thrilled with the Adobe provided method, i.e. sneakernet).

You have a couple of options; you can make some registry changes via Powershell or VB Script, among other methods. Some admins have used packaging software to create transforms that can be referenced. Others have gone so far as to repackages Shockwave altogether. 

Note: We recommend against repackaging. There are a lot of moving parts in these installers, not to mention the fact that repackaging Shockwave may violate your Adobe distribution agreement.

Whatever the case, I was disappointed to find that no simple solution existed for stopping the autoupdate during installation. Hopefully Adobe makes a change in the future.

I’m a little flustered. I feel like I’ve not adequately captured the frustration of many sys admins who have posted their frustrations to the Internet Machine.

If, by chance, Adobe has made the change to their installer, then my apologies. Please leave a comment with the installation parameters and I’ll update the post.

If you get frustrated with this product, rest assured, after digging around for a quick Autoupdate solution it became apparent that many a sys admin became alcoholics working with this application.

Speaking of drinking, here is a link to Adam’s ever popular Sys Admin Drinking Game.


Get your free copy of PDQ Deploy today.

Follow me on Twitter @ShawnAnderson

Follow Adam on Twitter @AdamRuth

 

PDQ Deploy 1.2 Beta

Uncategorized

PDQ Deploy and PDQ Deploy Pro are nearly ready to start beta testing for version 1.2. If you’re interested helping us test these new versions or just want to see what’s new, please sign up for the beta. You can sign up for either or both. Once the betas are available we will contact you with information about downloading them and, in the case of Pro, getting you a beta license key.

Sign up for PDQ Deploy Beta

Sign up for PDQ Deploy Pro Beta

In order to whet your appetite, here’s a sneak peek at the features you will see in these new versions.

PDQ Deploy Logo

PDQ Deploy

  • Organize installers into folders, making it easier to keep track of large numbers of installers.
  • Deploy scripts written in VB Script or PowerShell.
  • Deploy registry files exported from regedit.exe.
  • View all deployments from all installers in a single list.
  • Export/import multiple installers in one file.

PDQ Deploy Logo

PDQ Deploy Pro

  • Everything from PDQ Deploy above.
  • View all schedules from all installers in a single list.
  • Multiple actions per installer. Create installers that include several applications, updates, or script files all in one deployment.
  • Command actions. Run commands on targets without the need to copy an installer file.
  • Improved setup which makes it easier to install and upgrade the database, server, and consoles.

Trust relationship fails when accessing ADMIN$ (admin share)

Uncategorized

When using PDQ Deploy (or Pro) you may see the following error message:

Failed to connect to ADMIN$ share -- Logon Failure: The target account name is incorrect.

admin$ error - admin share

The Admin share (ADMIN$) is a default share within Windows and PDQ Deploy must be able to write to this share location.

To generate this error manually, simply open the run command and attempt to whack into the system as follows:

\\computer_name\admin$

Using the hostname you may see the same message received within PDQ Deploy.

admin share hostname error

If you’ve verified that the firewall isn’t blocking your admin connections, try whacking into the same system using the IP Address.

\\ip_address\admin$

admin$ - admin share error by ip - broken trust relationship

Ahh hah. Now we’re getting somewhere. The trust relationship between this workstation and the domain controller has become courrupted. This can be frustrating because you may well be able to log into this effected workstation using the same admin credentials that are failing to access the admin$ (thus making the trust problem difficult to isolate).

There are some reasons that can cause a trust relationship to fail, including discrepancies in system time differences from domain to workstation, corrupt account info in the domain database, and other items.

Here is a Microsoft KB article on how to fix the trust relationship.

We’d really love to say that there was a fast fix, but in our digging we’ve pretty come to the conclusion that you need to rejoin the workstation to the domain. A pain to say the least, but it’s effective.

This information is also available in our Admin Arsenal forum.


Download your free copy of PDQ Deploy

Follow me on Twitter @ShawnAnderson

Announcement: PDQ Deploy 1.1.4

Uncategorized

We’ve recently reached a milestone with version 1.2 of both PDQ Deploy and PDQ Deploy Pro which will both begin beta testing next month. They both have some new features which we think you’re going to love, and we’ll detail them in a future blog post. 

In the mean time we’ve recently updated PDQ Deploy to version 1.1.4 which has a couple of bug fixes from 1.1.3. You can download the update from here which will install right over any previous version.

Update Notes

We maintain a list of changes in the
online documentation
which you can peruse for any future or past version. In the latest version are the following two fixes:

  • Fixed a problem when loading up with a corrupted database file.
    This would have caused a crash at application start if the database file has certain types of corruption.
  • Fixed a problem when deploying some files which are marked read only.
    If source installer files were marked read only it could cause an “Access Denied” error to be reported and the install would abort.

As always, please let us know how our products are doing for you and if there’s anything you’d like to see us add or change.

5 (wrong) reasons why SaaS solutions are avoided

Uncategorized
SaaS - Give it a chance
Photo by stevoarnold

I love the premise of cloud computing. Rapid development, regular release cycles, continuous improvement, the list goes on.

So why are so many businesses still stuck in the desktop app mind set?

  1. Fear of losing control of their data
  2. Fear of slow connection
  3. Fear of no connection
  4. Perceived browser limitations
  5. Desire for offline access

Fear of losing control of your data.

Perhaps the biggest surprise in my professional career working with System Administrators is how very few Sys Admins have a deep knowledge of databases. In short, a system admin is not a DBA (exceptions exist of course, but they are just that; exceptions).

In large, well funded organizations there is often a clear deliniation between DBA’s and Sys Admins. But many other companies don’t make this distinction. To them everything that runs on a computer is IT. Their IT guy is Josh. He’s in charge of everything. He knows everything. He’s an IT god. How tough can it be to manage a database as well?

Sorry. I’ve seen single sys admins in many, many organizations, and nothing against them, but I rarely see one who is extremely proficient as a sys admin AND a DBA. The positions are simply too different.

My point here is, a company that is selling a SaaS offering will, in my opinion, best most companies in the following:

  • storage of data
  • confidentiality of data
  • integrity of data.

It’s their job. They do it everyday for hundreds or thousands of customers.

Fear of slow connection

This is a real concern. Our developers are in Australia, just south of Brisbane (where the photo above was taken). The rest of us are in North America. We use many SaaS offerings for a wide array of needs, from support tickets to accounting, and slow connections are sometimes a pain. But we are also very cognitive of the benefits of SaaS, and the ability to connect from anywhere. Slow connections here and there haven’t soured us, though we freely admit, blazing fast access all the time would be nice.

Fear of no connection

Your concern is noted. But if you lose connection now with your desktop app how proficient would you be?  Even desktop applications are becoming more reliant on internet connections, and as such, internet connections have gotten more reliable.

If you can’t afford to have an applications down for 40 minutes here and there, perhaps you should stay on the desktop side. But really determine critical vs. nice-to-have. Many SaaS solutions boast great availability. They have to. If they don’t, they won’t be a SaaS for long.

Perceived browser limitations

The first browser app I ever worked with was a firewall app back in ’98. Boy did that thing suck. One page with endless scrolling. We’ve come a long way since those days. So long that some SaaS solutions don’t require web browsers to do the work (hello Dropbox). Really look at the solution – see what is browser based and what isn’t. Even those items that are browser based have a lot of functionality. This is one area where I applauded 37 Signals – in 2008 they announced that they
were ending support for IE6,
even while millions of consumers were still using that abhorrent version.

IE6 simply didn’t provide the level of customer usability that they demanded, and they said so with no reservation or remorse.

Desire for offline access

OK, this is a good point. And to the extent that you really need true offline access, it may be a deal killer.

If you have closed labs and your solutions must be tested in those labs, then you have some choices to make. Hopefully your management will not categorically deny the ability to use SaaS solutions because of this, but they may. Doing so will surely be felt in the long run.

SaaS is here to stay. It may not kill the desktop app, but it certainly provides a level of customer usability that is lacking the in world of setup.exe.

Categorically refusing to use SaaS solutions will greatly limit your potential tools in your toolbox or weapons in your arsenal.

We’re an app company. We use SaaS for many of our company needs, and we’re excited to introduce this concept to our own product line in the very near future.


Install software silently using PDQ Deploy – a free tool from Admin Arsenal

Follow me on Twitter @ShawnAnderson

Deploy PowerShell 2.0: Distribute to your PCs with PDQ Deploy

Uncategorized
Shane Corellian Raindog Sys Admin
Photo by Helen Rosemier

OK, if you don’t have PowerShell 2.0 on your Windows computers it’s time to gird up your loins and just do it.

Thankfully, PowerShell comes included with Windows 7 and Server 2008 R2. For your other Windows OSes go grab the appropriate install file. If you don’t already use PDQ Deploy for your simple software deployment needs then grab a free copy right here.

It’s quite simple to deploy, actually. Just grab the installer file appropriate for your target OS create a deployment in PDQ Deploy

Below is a screenshot of a basic Installation of Windows PowerShell 2.0 for Vista/2008 32-bit computers.

blog spc 20101215 PowerShellInstaller

PowerShell is here to stay and it is a great shell which is something that Windows has been lacking for a long time. I remember when I first started playing with PowerShell back in 2007 I was hooked. For Windows Sys Admins this is a must-use technology.

We are going to add the ability to run PowerShell scripts natively from PDQ Deploy. So get PowerShell 2.0 on your targets systems sooner rather than later… perhaps the slow holiday season perhaps?


Follow me on Twitter @ShaneCorellian

When Computers Go Wrong

Uncategorized
Explosion. Waziristan
Photo by Northampton Museum

PC Pro has an interesting (if somewhat frightening) article on the “10 most calamitous computer cock-ups.” It got me to thinking about all of the times I’ve screwed things up either with code I’ve written or by some administration task I’ve performed. I dare not count them for fear that the number may be bigger than I think (and I can think of a pretty big number!)

What makes these 10 stand out is not so much the mistakes themselves, but the scale of their effect. They are particularly calamitous not because the scope of the error was so large but because the reach of the technology in question. In our own environments, our mistakes are not less calamitous with their own scopes. Accidentally deleting a bunch of user accounts or erasing backup files won’t quite effect the same number of people as the blowing up of a gas pipeline, but try telling that to your users when they can’t do their work.

Perhaps progress isn’t so much a measure of success, but the size of the potential problems. If you are at the point where a simple mistake can cost thousands of hours of productivity, then you’ve progressed through a series of smaller tragedies to get there. I don’t think I’d want anyone in a position to cause a lot of damage unless they’ve learned how to deal with causing a lot of damage. And learned to be sufficiently scared of pressing the “Submit” button. Not so scared that they don’t dare to push it, but scared enough to make it clear that they understand what pushing it may mean. To painfully twist a famous phrase: If you aren’t terrified of making a change to production, then you don’t fully understand what production is.

Install VNC Silently – Deploy RealVNC with PDQ Deploy

Uncategorized
Shane Corellian Raindog Sys Admin
Photo by Helen Rosemier

Every System Administrator needs, at some point, to initiate Remote Control sessions on computers across his/her network. Some standard tools bundled with Windows are Remote Desktop and Remote Assist. We’ve also discussed how to use DameWare Mini Remote Control via AA Console. One remote control tool that has been widely used RealVNC. There is a free version available but if you want to initate remote control sessions on Windows Vista, Windows 7 or Windows 2008 then you are going to need to spring for the paid version.

If you want to deploy RealVNC out to your enterprise then you need to obtain a license from RealVNC. Once you have the license you can simply pass the license key into your deployment configuration settings and you’re off to the races.

If you’d like to look at our RealVNC Deployment files feel free to download them, just remember that you will need to obtain your own license key from RealVNC.

As there are several steps involved in installing and configuring VNC we decided to use a batch file to carry out the instructions. (See video.)

Here is the body of our script:

@echo off
start /w vnc-E4_5_4-x86_x64_win32.exe /SP- /VERYSILENT  /COMPONENTS="!vncviewer,WinVNC,WinVNC/VNCMirror" /TASKS="!quicklaunchicon, !desktopicon, installservice, launchservice"
regedit /s RealVNC.reg

IF EXIST "%SYSTEMDRIVE%\Program Files\RealVNC\VNC4" (    
    "%SYSTEMDRIVE%\Program Files\RealVNC\VNC4\vncconfig.exe" -license ENTER-VNC-LICENSE-HERE
    "%SYSTEMDRIVE%\Program Files\RealVNC\VNC4\vncconfig.exe" -service -generatekeys
)

This script will install the VNC service but NOT the VNC Viewer. (Thus the “!vncviewer” value in components above) The Viewer is only needed by those who want to initiate a remote control session. Since most computers will only be targets of a VNC Remote Control session (i.e. these computers will be remotely controlled at some point) they don’t need the VNC Viewer. Feel free to download a
PDQ Deploy installer file
for TightVNC (as well as the .reg and .bat file shown in the above example).

Here’s a video demonstration of a VNC silent deployment.

Software Deployment Tip: Deploy .NET to Server 2008 R2

Uncategorized

While working on the next version of PDQ Deploy Pro we ran into an interesting problem. On Windows Server 2008 R2 it is not possible to use the standard .NET Framework 3.5 SP 1 installer, the installation must be performed through the Server Manager. Server 2008 and Server 2003 have similar restrictions with earlier versions of .NET.

Screen shot 2010 12 08 at 9.30.23 AM

So, if you come across the need to deploy .NET 3.5 to Server 2008 R2 you need to execute the Server Manager installation instead of the normal installer package. To do this remotely, create a batch file with the following command.

powershell -command import-module servermanager ; add-windowsfeature net-framework-core 

Deploying this batch file will get 3.5 up and running on your Server 2008 R2 systems. The install is quite a bit faster than the standard installer as many of the .NET components are already installed as part of other features.

Note: This particular command requires at least version 1.1 (release 3) of PDQ Deploy Pro and PDQ Deploy or version 1.5.0.15 of AA Console, all of which were released this week. This is due to a fix in them which allowed access to certain parts of a 64-bit computer’s file system.

?