Marimba SHOWCASES Embedded management solutions at embedded systems conference


MOUNTAIN VIEW, Calif., - March 11, 2002 - Marimba, Inc. (Nasdaq: MRBA), a leading provider of systems management solutions built for e-business, today announced that it will feature its Embedded Management products at the Embedded Systems Conference on March 13-15, 2002 in San Francisco. Conference attendees may visit Marimba in Exhibit Booth #1638.

Marimba's Embedded Management products help ISVs, server appliance, and home networking vendors accelerate time to market, reduce support costs, and improve quality of service. These customers use Marimba's solution to embed management capabilities into their products, allowing them to transparently deliver and install updates to end-points in the form of OS updates, application fixes, and new features.

The Embedded Systems Conference focuses on the latest innovations and everything that's going on in the embedded industry. It also provides opportunities for engineers, developers, and project managers to learn more about the latest technologies and discover practical embedded solutions. More information about the conference in San Francisco is available at: http://www.esconline.com/sf/.

About Marimba

Headquartered in Mountain View, Calif., Marimba, Inc. Nasdaq: MRBA) provides systems management solutions built for e-business. Marimba's Server Management, Desktop/Mobile Management, and Embedded Management product families allow Global 2000 companies to better manage their IT resources, increase operational efficiency and reduce IT costs. For more information, please call 888-800-5444, or visit our Web site at


# # #

Marimba is a registered trademark of Marimba, Inc. in the U.S. and/or certain other countries. Other product, trademark, company or service names mentioned herein are the property of their respective owners.

Be the first to comment

Phoenix Technologies Acquires StorageSoft, Inc.


Expands Phoenix FirstWare™ Products and Distribution Channel for PC System Builders, "WhiteBox" Manufacturers, OEMs, and Corporate IT Departments

SAN JOSE, Calif., January 9, 2002 - Phoenix Technologies Ltd. (Nasdaq: PTEC), a global leader in device-enabling and management software products, today announced it has acquired StorageSoft, Inc., a software developer of PC system builder tools and hard drive utilities, based in Louisville, Colorado. This completes an agreement to acquire StorageSoft that was previously announced on January 3, 2002. With the acquisition, Phoenix is further expanding its next-generation FirstWareTM product line and distribution channels in the "WhiteBox" manufacturing, PC system builder, and corporate markets.

For more than 22 years, Phoenix has demonstrated a successful track record of supplying system software solutions to PC OEM's and motherboard manufacturers. With the acquisition of StorageSoft, Phoenix broadens its technology, market, and customer base by providing software solutions for PC system builders and corporate IT managers, in addition to its more traditional customers. By combining Phoenix's firmware and software expertise with StorageSoft's proven hard-drive utility technology, expertise, and leadership, Phoenix will build upon the collective strengths to expand the FirstWare product line which makes the configuration, deployment, management, and support of PC's easier. Introduced in 2001, FirstWare is a breakthrough, secure, pre-OS environment ideal for storing and managing hard drive images and diagnostic tools.

"The StorageSoft acquisition is exciting news because it is another step towards achieving our strategic goal of becoming the leading provider of standard system software products for branded OEM customers, 'White Box' manufacturers, system integrators, and corporate IT groups," said Albert E. Sisto, Chairman, President, and CEO of Phoenix Technologies. "By integrating StorageSoft's powerful hard drive technologies with our next-generation FirstWare applications, we are creating a line of best-of-breed solutions that benefit a broader range of customers than ever before. The combined solution continues our tradition of finding new ways to help customers reduce manufacturing and support costs, increase revenue, and enhance the satisfaction of their customers."

StorageSoft's ImageCast™ product complements FirstWare by enabling rapid duplication, deployment, and management of hard drive images. With this technology, Phoenix will be able to supply customers with a "one-stop-solution" for a wide range of applications, from manufacturing to end-user disaster recovery. For example, system integrators, who generate revenue both by building systems and by providing support, will benefit by the intelligent integration of manufacturing tools and self-contained customer support solutions into their offerings.

Further, StorageSoft technology provides customers with the ability to configure new hard drives and legacy systems with FirstWare applications, even for PC's without Phoenix's FirstWare-enabled BIOS. This greatly expands the number of PCs that can benefit from Phoenix's FirstRescue recovery tools - "always-available" pre-OS solutions designed to significantly reduce customer support costs.

In addition to product and technology benefits, the acquisition also creates an expanded and strengthened new distribution channel for the combined solution by integrating the channel sales organizations and customer bases of both companies.

About Phoenix

Phoenix Technologies (Nasdaq:PTEC - news); Founded in 1979, Phoenix is a global leader in device-enabling and management software products for PCs and other connected digital devices. Its FirstWare™ family of "instant on" software activates, secures, connects and recovers digital devices and is designed into millions of industry standard desktop, notebook, server, and information appliance systems sold annually. This enables Phoenix customers -- specifiers, developers and manufacturers of user-driven microprocessor systems -- to reduce costs and provide high value-added features to their customers. Headquartered in San Jose, CA, Phoenix Technologies has offices worldwide.

For more information about Phoenix Technologies, visit our website at http://www.phoenix.com/.

About StorageSoft

StorageSoft develops drive diagnostic utilities and hard drive imaging software that reduces the cost to own, deploy, and manage multiple PCs. StorageSoft distributes more than 50 million copies of its software each year to corporate IT, VARs, system integrators, and OEM markets worldwide. StorageSoft is a privately held company based in Louisville, Colorado, USA, with sales and support offices in California, Wisconsin and The Netherlands.

"Safe Harbor" Statement under the Private Securities Litigation Reform Act of 1995:

With the exception of historical information, the statements set forth above include forward-looking statements that involve risk and uncertainties. Factors which could cause actual results to differ materially from those in the forward-looking statements are also discussed in the Company's filings with the Securities and Exchange Commission, including its recent filings on Form 10-K, filed December 5, 2001 and Form 10-Q, filed August 3, 2001.

Note to Editors: Phoenix and Phoenix Technologies are registered trademarks of Phoenix Technologies. All other trademarks are the property of their respective owners.

Be the first to comment

AppDeploy Command Line Installation Tips

Command Line Installations
Triggering unattended application installation from the command line.

The surest way to deploy an application with the least amount of issues is to use the setup routine designed for the application in the first place. Repackaging is necessary when a using a deployment tool that requires it, or when a command line installation is not supported. Often poorly documented, or not at all, you may find it difficult to discover how to go about this. You may also be surprised at the number of ways that exist to silently install an application from the command line when you know where to look and what to try. By "from the command line" we are talking about the use of command line switches to initiate the unattended installation of software such as "SETUP.EXE /SILENT". There are a number of steps you can take in your attempt to uncover a means of command line installation and we will cover them all here. As always, if you know of something over looked, shared in the comments below!

  • Check Your Resources: Places To Look 
  • Windows Installer Setups
  • Built In Command Line Support
  • Troubleshooting Your Command Line Installation

Check Your Resources: Places To Look


It is the goal of ITNinja to be the best place to start your search for any information relating to deployment. This especially includes how to deploy various applications. In working toward this goal ITNinja offers a Software Knowledge Base. This feature of our site provides consolidated details on the deployment of specific applications. We also have a well used Q&A feature here where you can ask others for help, or just see if another visitor has already addressed your question.

Included Product Documentation

In the form of a README.TXT or other included document you may get lucky and find the information you need. Unfortunately, vendors make it difficult if not impossible to scrape together any help by very often overlooking the issue of remote deployment altogether. Still, to expend efforts trying to uncover information that may have been provided to you up front is certainly not the best use of your time. Take a look- you may be fortunate enough to have the answer right in your hands.

Online Support

Many vendors now provide a knowledge base and user forums at their websites. This is an excellent source for finding silent installation information. You are unlikely to find much information in a FAQ, but there may be a knowledge base article covering the topic. The most likely place though, is the user forums or message boards where another user has come before you in search of the same information.

SMS Package Definition File (PDF)

No matter if you are using SMS or not, a Package Definition File is a great source of command line options if your software happens to include one.

PDF files are actually INI files, which may be viewed with a simple text editor such as notepad. Look for the "COMMANDLINE" entries in the file for unattended installation command lines. Many older Microsoft applications include PDF files and there have been a number of other software companies that had deployment of their applications in mind and also provided a PDF. For more information on PDF files check here.

Windows Installer (MSI) Setups

Microsoft's new Windows Installer format is the latest answer to solving issues with installation, removal and, yes, deployment of applications. A Windows Installer based installation is currently a logo requirement for Windows 2000 (and later) compatibility. This means more and more applications are surfacing as MSI installations. You are still likely to see a "setup.exe" so don't stop looking when you see it. A program named setup.exe is still often included as a wrapper for the Windows Installer installation, which checks for the existence or for the installed version of the Windows Installer service. If it is missing or out of date, the setup.exe will install or update the service before triggering the Windows Installer installation process. Do a search of your installation media for a file with a "MSI" extension to be certain. When found your command line installation just became one of the best documented of its kind:

I recommend the following command line for the silent installation of MSI setups:

MSIEXEC.EXE /I "path and filename of MSI" /QB- /LWAMOE c:\temp\install.log ALLUSERS=1

  • MSIEXEC.EXE - the MSI executable, the program that performs the actual installation of the application.
  • /I - this switch informs the Windows Installer to install the specified application (as opposed to removing, reinstalling or repairing the application)
  • /QB-  - this switch instructs the Windows Installer to perform the installation with a basic user interface requiring no dialog boxes to be displayed. You might also use /QN to perform the installation with no user interface at all.
  • /LWAMOE c:\temp\install.log - this switch instructs the Windows Installer to generate a log file at the specified path and file name (in this case, "c:\temp\install.log") and to include the following details: Non fatal errors, start up actions, out of memory or fatal exit information, out of disk space messages and all error messages. There are several other options (see the AppDeploy FAQ for more details) to include all possible details in the log file use "/L* c:\temp\install.log"
  • ALLUSERS=1 - including this will cause the shortcuts for the application to be placed in "all users" instead of the current user profile.

See the Windows Installer (MSI) tag for more information.

Built In Command Line Support

If your installation is not a Windows Installer setup and no specific information can be uncovered regarding a means of silent installation, you may still have a very good alternative. If the setup.exe was created with an InstallSheild authoring program, a number of command line switches are supported by the setup that may help you to deploy it.

Integral is the ability to create an answer file and then use that answer file to perform the silent installation of the application. It does not always work just the way you would like, and keep in mind that the vendor may not even be aware of this ability they have provided. However, it often works just fine and should be pursued as a means of deployment before resorting to repackaging the application.

Create an answer file by launching the setup with the "/r" switch. This will take you through the normal series of dialogs to the completed installation of the application. When done, simply copy the "setup.iss" file created in your system directory (normally, c:\winnt\setup.iss) and place it in a folder along with the application's other installation files. This folder is often a copy of the installation CD on a network share, but the end result should be that you have your created setup.iss file and the application's setup.exe file in the same folder.

To kick off the silent installation of the application you may now simply specify the "/s" switch to make use of the answer file you have created. During installation there will be no prompts or indications the installation is taking place or complete. View the Windows Task Manager to see the process activity if you are interested.

You can view the setup.iss file in a simple text editor such as notepad to see what was recorded in the answer file. If serial number information was requested during installation, you will hopefully see it reflected here. This is most often the point of failure for use of an answer file such as this. If the capture of your responses does not include the serial number information, or any information for that matter, the installation may hang, fail or a pop up dialog may be presented requesting missing information. For this reason through testing should be performed (as always.)

See our full listing of InstallShield command line switches for more detail.

Troubleshooting Your Command Line Installation

Nothing happens at all? If you are watching the task manager processes and do not even see your setup initiating, your call to it is in error. Make sure all files referenced are where you are specifying them to be. If you are not specifying a path, that too can be your problem. In a batch file for instance, the current directory may reset to the system directory where your installation files can no longer be found. To ensure this is not your problem, specify the entire path to all files referenced (when spaces are involved in directory or file names, be sure to include them in double quotes.)


If something goes wrong during installation, you may see the dialog with the progress bar moving in reverse. This means an error was encountered and the Windows Installer is putting everything back the way it was to avoid problems. You can easily see what the problem is by viewing the log file created by the Windows Installer (see recommended command line above with /L switch)


If you see your setup start in the Windows Task Manager (processes tab) and it remains while utilizing zero CPU cycles- you have a problem. Likely there is a dialog response not being provided by the answer file and due to the lack of a display, you cannot see where the problem lies. For more switches you can use in troubleshooting, check here.

No SETUP.ISS file is generated? First make sure you are dealing with an InstallShield setup. Some vendors have been known to wrap their setup programs in self-extracting archives. If you believe this to be the case for your situation, initiate the installation and at the first dialog prompt change windows (do not abort the installation) and browse to the TEMP directory (by default this is in your profile directory "C:\Documents and Settings\username\Local Settings\Temp" for Windows 2000 and later). Here you may find a temporary directory generated that contains the actual installation files. You may then copy the installation files from this directory elsewhere (it is removed when the setup is completed or aborted.) The copy of setup.exe found here is very likely to support the process documented above (if it is an InstallShield setup and not an MSI setup or other vendor generated setup program.)

Check the log file generated in the setup.exe directory for its [ResponseResult] section. InstallShield places one of the following return values after the ResultCode keyname:

0 Success.
-1 General error.
-2 Invalid mode.
-3 Required data not found in the Setup.iss file.
-4 Not enough memory available.
-5 File does not exist.
-6 Cannot write to the response file.
-7 Unable to write to the log file.
-8 Invalid path to the InstallShield Silent response file.
-9 Not a valid list type (string or number).
-10 Data type is invalid.
-11 Unknown error during setup.
-12 Dialogs are out of order.
-51 Cannot create the specified folder.
-52 Cannot access the specified file or folder.
-53 Invalid option selected.

Still No Luck?

Perhaps there is some undocumented process you can uncover. Below are some command lines found to work for other applications in the past, try "setup.exe /?" first then go through the list below- you may get lucky!

  • setup.exe /q
  • setup.exe /qn
  • setup.exe /silent
  • setup.exe /s
  • setup.exe /NoUserInput
  • setup.exe /unattended
  • setup.exe /CreateAnswerFile
  • setup.exe /quiet

Please use our Q&A system to discuss these and other issues regarding the deployment of specific applications and deployment in general. Here the maximum number of experienced desktop engineers will have an opportunity to respond and all may benefit from it.

 Bob Kelly 9/23/01, Updated for ITNinja references/links on 11/8/12

View comments (1)

AppDeploy - Imaging Windows 2000

Home > Articles > Imaging Windows 2000

 Imaging Windows 2000

Deployment of a new client operating system is obviously a significant change for a network. The smoothest path to Windows 2000 is to upgrade your existing workstations using Microsoft’s extensive unattended setup options. In this way, you can keep the applications and settings in place that will ease the change on users. However, for many the upgrade to Windows 2000 is an opportunity to start fresh.

Years of installations, upgrades, removals and fixes leave a workstation in a state prone to various problems. Deploying a new drive image to workstations may be the answer to crushing the mess that has become of your workstations and at the same time allow you to standardize your new Windows 2000 baseline.  Here we will cover some tips and things to watch out for when imaging Windows 2000.

You may not be able to use the same image on all of your workstations. The hardware abstraction layer (HAL) for one computer will not work on a machine of a conflicting hardware configuration. Microsoft managed to reduce the number of scenarios where this would be an issue to two cases: Advanced Configuration and Power Interface (ACPI) and non-ACPI HALs are not compatible.

Not long ago, there were issues between uniprocessor and multiprocessor computers as well. An image may now be created on a multiprocessor computer, and then by implementing options available in SysPrep, the Windows 2000 installation will determine if a one or more processors are running and automatically use the correct kernel files following the Mini-Setup stage of the installation. 

As for the ACPI and non-ACPI compatibility issues, it is reportedly acceptable to image the lowest common denominator. An image with no power management (non-ACPI) can be applied to all workstations, but those workstations with power management features (ACPI) will loose those benefits. The opposite is not true; you cannot image a machine that does not have power management features (non-ACPI) using an image created on a machine that had such features (ACPI). The conversion from APM to ACPI is possible only through a reinstallation of Windows 2000.

The image may be a bit larger than expected, and there are a couple of reasons for this. The main culprit is the new Windows File Protection (WFP) feature in Windows 2000 that stores copies of system files in a “DLLcache” folder on the boot volume. When any of these protected files are removed or replaced, WFP will take the copy from the DLLcache and put it back again to ensure these desired files are always in place. The problem is that this DLLcache folder is hundreds of megabytes in size (the default setting is 400mb or approximately 2700 files.)  This problem is compounded further by the fact that when a Windows 2000 service pack is applied, instead of updating the files in the DLLcache, a second copy of the files are placed on the system. The System File Checker (SFC) tool checks the service pack location first and then the main DLLcache folder to find the desired files enforced by WFP. This second copy means that this feature may consume even more space.

This default setting may be adjusted by changing the size of the “SFCQuota” value in the registry (See knowledge base article Q222193 for details.) If by reducing the size of the cache, WFP detects a deletion or replacement of a file that it does not have a copy of in its DLLcache, it will look to the installation point for this file. If the installation were performed from a CD, the user would be prompted to insert the CD. However if the source were a network location available to the workstation, the files would be obtained from that point without prompting the user for media. This is a trade off that will have to be considered prior to deployment, if the space is available locally, it is best to keep these system-protected files locally.

Another reason the image may be so large is that the page file is part of the image. SysDiff contains an option called, “KeepPageFile” and by default this value is set to zero, which tells SysPrep to regenerate the page file. It does not however remove the page file from the image as indicated in the documentation. You can however, use the "Clear Virtual Memory Page File When System Shuts Down" policy in Windows 2000's Local Computer Policy to zero both the pagefile and the hibernation file (hiberfil.sys) which will free considerable space.

SysDiff for Windows 2000 is much more robust than its NT predecessor. SysPrep now supports a new “-pnp” switch that informs the Mini-Setup to rerun the full PnP device enumeration and installation on the computer. If plug and play does not detect all components on a networks range of hardware, it can be further manipulated to do so. Non-plug and play devices must have their drivers contained within the image.

SysPrep requires that the mass storage controller on the master computer be identical to the controller on the destination computer.  To support other mass storage devices for your image, they may be identified manually in the Sysprep.inf file before creating the master image. A section named, “SysprepMassStorage” must be added to the Sysprep.inf file listing each hardware id and its associated device INF file. One of the drawbacks of this is that the devices will be present on all machines the image is applied to. This may be cause for some confusion for some inventory software. The undocumented SysPrep switch, “-clean” may be used to remove unused mass storage devices. Those who worked with Windows NT unattended installs will be familiar with commandlines.txt, which is essentially a batch file executed following an unattended installation. This feature is now available to SysPrep itself and can be used to automate any number of scripted actions following the application of a new image. In this case adding “sysprep.exe –clean” will automatically remove unused mass storage devices following the Mini-Setup.

Support for the imaging of Windows 2000 is greatly improved, but as with any process there are always hurdles to overcome. Be sure to check back to AppDeploySM for more information on this and related issues in the future. Share your problems and solutions on imaging at our imaging forum!

Bob Kelly

Be the first to comment

AppDeploy: Articles: Custom Deployment Scripts

Home > Articles > Custom Deployment Scripts: Pluses and Minuses

 Custom Deployment Scripts: Pluses and Minuses

If you take a look at the survey on our home page, you'll see that a surprising number of visitors use a custom script to handle their network software deployments. Why is this? Many have tried one of the more well known products like SMS or Tivoli, ran into problems and in the process of scripting solutions around the problems, developed an entire scripted solution. Cost is another key reason for going with a customized deployment, purchasing deployment software and client licenses become an increasing issue as the size of the network to be managed grows in size. Automation must exist, configuration management is impossible to maintain without some level of centralized management. Increasing the cost of many commercial off the shelf (COTS) products is the fact that so many include a suite of applications or some framework, which by definition, is very complex and even more often expensive. A final reason, not often considered, is that until AppDeploySM there was nowhere to learn of the competition to the more recognized products and their capabilities. Being that the market for application deployment tools is still very immature, there has been little information to assist administrators in making an educated choice which best meets their needs.

However there are also several reasons not to go with a customized solution. One large one is support. A COTS product provides you with a help desk, regular updates, documentation, and in some cases training and technical papers. The support that comes with a customized deployment script is limited to what can be accomplished by the individuals familiar with the script. This brings to light the largest problem, normally there are only a small number of people intimately familiar enough with the script to troubleshoot problems and implement enhancements. The retention of these individuals cannot be guaranteed.  For this reason, thorough documentation is essential. It is very common that documentation for custom deployment scripts is poor or non-existent. Optimally, documentation would pull apart and explain the script to a level that anyone could understand. Finally, almost all scripted solutions rely on the population and placement of text files that can be easy to confuse as compared to the simplicity of a graphical user interface. Blinding the operator of the script from seeing exactly what actions are taking place can have potentially catastrophic effects for inexperienced operators.

            Take some steps toward a making an educated assessment of your situation. In the creation and use of custom deployment scripts, sufficient experience should be on hand to develop a proper set of requirements for a COTS replacement. A list of what you need in a replacement is essential. There may be no product that meets your requirements; there may also be some essential functionality you didn’t consider. This may be an exercise fraught with resistance by those who generated and maintain the custom script. However these are the people who know the requirements best, and are therefore essential in the process of building and researching a COTS replacement.

If and when solutions are uncovered, it may still not be the right time to make a switch. Financially there may not be the money available for the product and there may be increased deployment activity taking place that requires you to stay on track until a later date.  But don’t catch yourself waiting for the time when no deployments of updates, fixes or new software is taking place- that day may never come.

Bob Kelly

Be the first to comment
Showing 3271 - 3275 of 3277 results