When creating a new protection group in DPM 2007 RTM you are presented with a list of computers on your network that have the DPM client installed. The DPM server itself is in this list as it also runs the client for various reasons, including the ability to be backed up by another DPM server.
When you go to expand the local DPM server node you find a very small, or non-existent list of data that can be protected. If you are running the DPM SQL database on the local machine, that will be the only thing available, otherwise there is absolutely nothing.
Local Protection Disabled
DPM 2007 SP1 now includes the ability to protect resources local to the DPM server itself. This feature is being described by Microsoft as a way to build an all-in-one branch office server. You can now run DPM on the same server that is providing file sharing, database, and other services to your branch office and use it to protect that data. Once the branch-offic DPM server is protecting its local data you can then use the DPM server at your main office to protect it, “Instant Disaster Recovery” says Microsoft.
Configuration
This new feature is implicitly disabled and must be enabled using a powershell cmdlet. Enable this feature using the Set-DPMGlobalProperty cmdlet, launch a DPM Management Shell session and enter the following incantation:
Set-DPMGlobalProperty –AllowLocalDataProtection $true my-dpm-server
If for some reason you need/want to disable this feature, just change $true to $false.
Now when creating a new protection group you should see the Shares and Volumes nodes available under your DPM server where only DPMDB existed before.
Local Protection Enabled
Using
This feature came not a moment too soon. We don’t currently need it for a branch-office configuration but I do need this feature rather badly for doing disk image backups of our VMWare infrastructure using DPM. VMWare’s Consolidated Backup mounts remote disk images as local directories, and without this feature I would have to use a third machine to act as the VCB proxy. Having a proxy would require not only another machine, but another node in the data flow between my VMs and tape.
I’ll explain indepth how I am using DPM to backup VMWare Infrastructur using VMWare Consolidated Backup in a future post.
Qualcomm Gobi WWAN Card on Windows 7
<Update>
The latest 64-bit version of most vendor’s drivers now work fine without following these instructions or using GobiLoader. I updated my Thinkpad to Win7 Retail x64 using Lenovo System Update to install all the drivers and now my Gobi card works great even after a sleep/hibernate.
</Update>
I have been surprised by the extremely small number of compromises that I’ve had to make after installing Windows 7. One of the more painful for myself however is the problem with support for my laptop’s internal WWAN card which is based on the Qualcomm Gobi chipset. It looks like this chipset is used on some HP laptops as well as my Lenovo Thinkpad (W500) and my Boss’ X301 for both Verizon and/or AT&T. This chipset is new from Qualcomm and is supposedly a global radio supporting any provider on both CDMA and GSM by using a dynamic firmware capability.
During the time of the Windows 7 beta and now the recent RC1 there have been some rumblings from people that need this support to be able to use Windows 7 full-time. Reading through the posts and trying to get this to work I’ve found there to be two blocking issues getting this card to work, the first is getting the drivers to install on Windows 7, and the second is getting the dynamic firmware to load onto the card.
Installing the Drivers
The problem with installing the drivers is caused by a library that Qualcomm uses to support the installation called difxapi. The supporting DLL for this API is included in the installation package and it conflicts with the Windows 7 version, this conflict causes a custom action in the installation routine to fail and forces a rollback of the installation.
To fix the problem we need only to replace this DLL with the one from your Windows 7 installation. If you don’t have it already you need to download the driver installation package from your laptop manufacturer’s support site and extract it somewhere.
Starting from where you unarchived your package look for a directory similar to “\Driver\Source\Module Retargetable Folder\QCUSB-Lenovo\DriverPackage\Microsoft\DIFxAPI”. Now you just need to replace the difxapi.dll here with the one from “c:\windows\system32\”. If you are running 64-bit Windows then copy the DLL into the amd64 subdirectory, for 32-bit installations copy the DLL into the x86 directory, if you’re not sure you can safely copy it into both directories.
Once you replace this DLL the setup.exe under the “Driver” directory should now run successfully. Once the installation finishes verify that you have the “QCUSB-*” and “QDLService” directories under “c:\QUALCOMM”.
Loading the Firmware
I’ve somewhat mimicked two Linux programs and wrote a tool called GobiLoader for Windows 7 that is able to successfully load firmware onto the card for any of the supported wireless providers (see More About the Firmware for more info).
Download GobiLoader
Since the Qualcomm service is not able to load the firmware properly we will need to disable it so that it doesn’t conflict with GobiLoader. Bring up the “Services” control panel and in the list of services find the one labeled “Qualcomm Gobi Download Service”. Double click the service to bring up the properties, if it is running click the stop button; to disable the service change the “Startup type” drop down to “Manual” and click “OK”.
Before you use GobiLoader you will need to verify that the proper firmware files will be loaded. To find the proper firmware files you can take a look at the Qualcomm Download Service log file on your Vista installation. The log file is called “QDLService.txt” and can be found under the “C:\Users\All Users\QUALCOMM\QDLService” directory. Open the log file and verify the path to the firmware files that it is loading, you will see something like this:
The number ‘1′ in the firmware path (C:\QUALCOMM\QDLService\Packages\1\amss.mbn) in this case is the ID for the firmware that my Vista installation was successfully using. Your number may be different depending on who your wireless provider is (AT&T, Verizon, Sprint).
Remembering the firmware number go back to Windows 7 and under the same “C:\Users\All Users\QUALCOMM\QDLService” directory open the “Options.txt” and verify that it is pointing at the correct firmware. After I installed the Qualcomm drivers on Windows 7 it was pointing at the wrong firmware so I had to manually correct the path. GobiLoader reads this file to load the correct firmware, so be sure it is correct or your card will not work. GobiLoader also assumes that the “Options.txt” file is located at “C:\Users\All Users\QUALCOMM\QDLService”; and it relies on the registry to detect which COM port that the QDLoader device is listening on.
Once you have everything in order you can simply run GobiLoader.exe and watch for a successful upload. Once the upload has happened you should see your WWAN modem become available.
You will need to run GobiLoader after any time that you shutdown, sleep, or hibernate your laptop.
More About The Firmware
Glancing at the firmware files I noticed that they had an ELF header, and running ‘file’ on them evoked this:
amss.mbn: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, strippedIt seems that the Qualcomm Gobi chipset runs embedded Linux on an ARM processor, and the firmware files are simply executable programs. When the firmware files are uploaded they are being copied into RAM and then run just like any other Linux program. Since these programs are in RAM they are lost every time the card gets power-cycled (including during sleep or hibernate) and the card reverts to a blank slate.
In its blank state the card’s built-in firmware exports a single USB serial port device — called HS-USB QDLoader — to the operating system, this port is used solely for the upload of the firmware files to the card. You can think of this built-in functionality as something like a bootloader.
I find this design rather ingenious, since the running firmware programs are simply Linux executables they’ve opened up the pool of capable developers considerably. Qualcomm should be able to be quite agile in fixing bugs and adding features since the developers can write user-mode programs, where most firmware is either bare metal or kernel-mode code. As the power of embedded processors grows I expect to see solutions like this become more common.
Once the firmware has been loaded, the QDLoader device goes away and the modem’s other ports attach to the system; these devices appear in the Windows device manager.
Gobi Devices After Firmware Load
The laptop manufacturer’s driver package installs a Windows service called “Qualcomm Gobi Download Service”, its job it is to upload these firmware files to the card after every power-cycle. Thanks to Alexander, Sergey and Mathew I was able to work out how the Download Service actually interacts with the card.
The Future
I don’t know how responsive Qualcomm is, so I don’t know how quickly these issues will be resolved; I would hope that as the Windows 7 release looms near that they will be prioritizing support. If these problems are not fixed soon then I will probably package GobiLoader up into a service that watches for the QDLoader port to load the firmware on-demand.
I’m also working on a post describing the handshake protocol in detail based on what I was able to gather from other code, protocol traces, and trial-and-error. Hopefully this detailed information can be useful in making the Linux support more robust, which — for me — is useful when firing up my Ubuntu partition.
Update:
I’ve cleaned up the source code and you can grab it here if you’d like to take a look or modify it. GobiLoader Source