Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Many larger organizations have IT departments that lock down desktops to a standard configuration, or SOE. End users generally don't have rights to install their own software, and even if they did, organizations tend to only allow "approved" software to be installed.

Even for free/open source software, end users often have to submit some kind of request form to have the software verified and approved. Once the process has been followed and the software is installed, upgrades can be troublesome - many organizations tend to stick with older versions of software (Windows XP, Office 2003, etc.) for fear of unknown issues.

What can software developers do to speed up the approval process?

If you are involved in such an approval process:

  1. What do you look for when evaluating software? For example:
    • Do you prefer MSI's or xcopy-able software?
    • If the software requires frameworks (Java, .NET) is that more or less likely to be problematic?
  2. If the software supports automatic updates, do you generally allow this?
  3. How long does it generally take?
  4. What kind of licensing models do you prefer (transferable, per-seat, per-CPU, site-wide)?
  5. What else can ISV's do to improve their chances of having their software approved?
share|improve this question
    
The vastness of the answers supplied to this question make it seem like it should be a community wiki –  Ryan Bolger Sep 13 '09 at 20:16
add comment

6 Answers

I'm part of the Software Approvals Group for a multi-national company and I would absolutely echo everything Adam says above.

I'd also make the following points, firstly always pay all of your "development taxes". This means making sure that your app works properly in a whole variety of environments that you may not ever use, but will very likely be deal-breakers for large companies, these are things like making sure that your app works well with roaming user profiles and redirected user folders (always use Windows APIs to find user and profile folders, don't ever assume they're at standard locations, or even on the local drive), making sure it plays well on Remote Desktop servers (where there might be a 100 copies of your app running at once, some using very slow connections), on laptops with slow network connections or low batteries and so on. As an example we recently rejected new versions of more than one piece of software from a very large company (starts with "A" and is famous for graphics) because their apps suddenly don't work with redirected home folders in the latest versions, this is a deal breaker for us.

Even for free/open source software, end users often have to submit some kind of request form to have the software verified and approved.

By the tone of your comment it sounds like you think the approval process has something to do with cost? From our point of view per-unit cost of an app isn't something we'd consider at all in the approval process. Financial justifications for apps will have been worked out, software approvals is all done from the technical and support-ability angle. Free and Open Source software generally has more trouble getting through our process than a proprietary commercial app. Often this is simply down to the lack of accountability. Who do you go to when there are problems with the app and you need support, what's their SLA? Who do you ask when you need to find out if the app will work with a new version of OtherApp v.X, are they really giving you an actual answer that people are really working towards, or is this a vague "someone in the community may do it" answer?

Once the process has been followed and the software is installed, upgrades can be troublesome - many organizations tend to stick with older versions of software (Windows XP, Office 2003, etc.) for fear of unknown issues.

Software upgrades have to go through the same process as totally new pieces of software do. The only advantage they have is that we'll already know the answers to some of the questions as we've already been supporting the software (this may not be a positive for the software, support teams have veto'd upgrades based on experience with the company).

Do you prefer MSI's or xcopy-able software?

Either of those deployment methods can be good, as long as they've been packaged properly. Otherwise we're quite likely to rip out your installer and repackage the software for deployment ourselves.

  • Whatever installer you use, you must make sure that you respect all of its silent, unattended install modes. If your app requires a manual install, that is an instant deal breaker, there simply is no practical way to do that across machines on 5 continents that get all non-hardware support from a central office.
  • Given the choice I'd prefer a well done MSI install to a well done xcopy install. The problem with most Xcopy-able pieces of software is when they try to setup and register themselves on first-run. I have very rarely found an app that does this properly and doesn't cause problems in a roaming user/hotdesk environment. MSI installers (if you stick to the standard API) aren't able to go too far wrong.
  • Make sure that your silent install gives the ability to make all configuration changes that can be made in a manual install. If you're using MSI and sticking to the API then this is fine, we can make MST transforms and do all this no problem. If you're using a different third party installer, then make sure it allows something like an "answer" file or an INI file or similar. Test the silent install and make sure all the options work, I've come across products that gleefully announce their silent install options, but they've never actually tested if all the options work.
  • Preferably give us extra options in the silent install that let us set a lot of the settings that a user would normally change in the Options panel. This could be by switches on the setup.exe, could be by having a documented INI file for the settings, by documenting the necessary registry changes, or all of the above. However it's done, we'd like to make sure that our users can get up and running with the software without having to do any configuration themselves, important ones here are default locations for files, default server names, proxy settings (if your app runs over a network), etc.

If the software requires frameworks (Java, .NET) is that more or less likely to be problematic?

It's definitely more problematic. Versioning in most frameworks and backwards/forwards compatibility is atrocious. With Java in particular many apps (and websites) require a particular major and minor version of Java installed and won't work with anything else. If you need to put three different apps on a machine that all need different versions of Java, and they're not happy with the standard ways of cloaking one Java version as another, then there will be problems. .Net has its own problems with versioning, but will happily let you install all major versions of the framework at the same time which gets around a lot of these.

If the software supports automatic updates, do you generally allow this?

Never. There are far too many versioning and inter-operability headaches to ever allow an app to update itself without any warning. App upgrades take testing and planning. Also users with normal user rights can't apply the updates anyway. If you use a deployment method that allows patching (eg use MSIs with MSP patches) then this can make things like security patching for apps far less of a headache, and we can manage the auto-updating ourselves using our deployment tools (WSUS and SMS). Also our security team are very suspicious of any app that "talks back to base", they like to know exactly what info it's sending and exactly why it needs to send anything to an unknown server over the internet.

How long does it generally take?

Some simple apps, and version upgrades can be decided in as long as it takes 6 people to click an "Approve" voting button in Outlook. More complex or controversial ones may wait for our group meeting every two weeks. Some apps may be talked about at more than one of these meetings as teams take questions about an app away and research/test.

What kind of licensing models do you prefer (transferable, per-seat, per-CPU, site-wide)?

Totally depends on how the app is going to be used, and by how many people. The most important thing is that your licensing is clearly defined. We have to send our people on (albeit free) courses to understand Microsoft licensing. We're not going to bother doing that for an ISV.

Consider our silent, automated install needs when it comes to licensing. If your licenses need activation we don't want to have to ring/email you every time we reinstall an app on a PC. If every copy of the app needs a separate, different license key typed in, then we can't deploy that automatically, whereas if we can buy a bulk (2, 10, 50, 500, etc seats) key that can be saved in the silent install, then we're happy. It's even better if we can go back to you a year later and negotiate to expand our number of licenses without having to change the key that's typed into the software.

What else can ISV's do to improve their chances of having their software approved?

We'll also look at things that aren't strictly related to how your app is at the moment. Bearing in mind that if your app becomes part of the standard workflow for one of our areas it might be used for 10 years or more, so what does your product's roadmap look like? If you don't support the latest brand-new or in development version of Windows yet, do you have a plan for when you will? Does it look like you stick to these roadmaps? Does it look like you have any plans for drastic changes to your app, either the way it works or the technologies/frameworks it uses? Does your app plug into any other apps, eg MS Office or IE, if so how tolerant is it of older or newer versions of those?

share|improve this answer
    
Good, comprehensive answer. Many of the things that GAThrawn specifies explicitly here are covered by the Windows logo program (e.g., paying your development taxes). –  Jay Michaud Sep 13 '09 at 13:48
    
+1 for the mere effort of answering each point. –  osij2is Sep 14 '09 at 3:05
add comment

We're quite a small organization, but moved to standard desktops and approved software to reduce our admin hassle.

Do you prefer MSI's or xcopy-able software?

Anything which can perform a "silent" install. MSI's generally work well here, but lots of installer software is fine too. If we have to configure it in some way then it's good to be able to script that too, either by xcopy-ing files or registry merging.

If the software requires frameworks (Java, .NET) is that more or less likely to be problematic?

It can be problematic because of the different version requirements. If you need .NET 3.5 and we're using 3.0 then we have to manage that upgrade and ensure it doesn't break anything else.

If the software supports automatic updates, do you generally allow this?

No. Too much risk of the new version causing issues. Also, users don't have Administrator rights so updates usually don't work anyway.

How long does it generally take?

If there's a pressing business need, as quickly as possible - as little as a few hours. For more awkward software, maybe a week or more.

What kind of licensing models do you prefer (transferable, per-seat, per-CPU, site-wide)?

The cheaper the better! We can deal with most reasonable options, but it gets hard if the software does any kind of automated checking or requires activation. These don't tend to deal well with dead PCs, failed activations etc., and generally make extra work for us.

What else can ISV's do to improve their chances of having their software approved?

Two things spring to mind:

  • Consider the difference between the machine (Program Files or HKLM) and the user profile (or HKCU) when storing settings. If you do this right then I won't have to sorry about it.
  • Document installation, settings and licensing details clearly either on your website or in your software documentation. It's much easier to follow a "deployment guide" than to try and figure it out for myself.

And of course you have to make software worth using in the first place - if the user really loves it, they're going to shout louder to get it approved!

share|improve this answer
add comment

The first thing I generally look at is - have you got the basics right? If you can't do that, then I will be incredibly reluctant to go any further. So I want to see an MSI installer with a standard customization tool to allow me to build a transform. I don't want to see any requirement for admin rights to install or use the software. I don't want to see any requirement to reconfigure PCs. I don't want to see per-user data written to per-computer locations. I don't want to see manual visits to desktops, I want to see proper remote management and configuration available via GPOs. In other words, do you understand the requirements of a managed corporate deployment?

If the software requires any kind of updates, it better be something akin to an AV definition file or similar, it better be possible to maintain your own central updates server if you want, and it better be fully and obviously centrally configurable. I don't mind software that comes with program updates so long as I can switch them off.

I don't want to see any internet communication from the software aside from that which is absolutely required in order for it to work. And it better be all documented. By letting your software onto my network I am placing trust in you to neither screw up nor be evil, so I expect that you won't betray that trust. If you do, I will be very disappointed. Remember - you are a guest in my house, so treat my house with respect.

NO JAVA. Java has in my experience caused utter havoc when it comes to deployment, every single time, mainly by getting all of the above wrong. I'm happy to accept .NET as it at least seems to be more sensibly designed from a central management perspective (plus a .NET app has a better chance of getting the basics right owing to constraints in the framework).

For licensing the first thing I will look for is a free trial version that I can download without having to register. If I don't see this I will probably suspect that you have something to hide. I'm fine with time-limited, but I don't like reduced functionality; after all, this is the stage at which I'm deciding if your software is going to be an acceptable guest in my house, so I want to be able to see everything.

I want a single license key for my entire site. Having to enter a separate license key on each PC breaks the "must have central admin/management" rule. Price yourself sensibly too, so that if I only need to install your software on 200 of my PCs I'm not paying the same as if I needed to install it on 1500.

Finally, ongoing support and maintenance is important. Getting the software in and on painlessly is only a small thing, after all, but how it behaves over time in regular day to day use is utterly critical. If I need to get in contact with you to resolve a problem, I don't expect any obstacles, and I don't expect you to start pushing the blame elsewhere without at least an investigation to establish the facts. I don't take kindly to any obvious attempt to rip me off in a maintenance contract either.

share|improve this answer
add comment

GAThrawn's answer covers most of what I was going to say. I want to expand a bit on the licensing aspect of things.

  • Apps that need to phone home to the mothership for licensing verification are usually denied. If you're really that protective of your software, provide a licensing server that we can host ourselves. This can be a 3rd party solution like FLEXlm or something you develop in house. FLEXlm is by far the most common in our environment.

  • Concurrent use licensing options are always a big plus.

  • If you make us host a license server, make sure the tcp/udp port it communicates on is configurable. DON'T ASSUME your license server is the only one running on the box.

  • All client/server interaction needs to be done without any end-user interaction.

  • A text file living on a network share that requires end-users to have write access IS NOT an acceptable licensing solution. Users do not have and will never have write access to our licensing or application servers. We're not going to make an exception for you. I don't care if you think we can keep it locked down with quotas and such. It's not worth the hassle and your software just isn't that important.

share|improve this answer
add comment

I'm going to answer #5 first, because it is the most important for me.

5. What else can ISV's do to improve their chances of having their software approved?

The number one thing you can do to is pass Windows logo testing. The "Designed for Windows" (or whatever they call it these days) program tests a number of program functions and system interactions that, if written according to the rules, reduce work for me and ensure a level of stability and usability for the users.

Here are answers to the rest of your questions in order:

  1. What do you look for when evaluating software? For example: Do you prefer MSI's or xcopy-able software? If the software requires frameworks (Java, .NET) is that more or less likely to be problematic?
    Always use an MSI installer in a single file if possible. This lets me deploy manually, with Group Policy, or with pretty much any software deployment tool I want. Windows Vista (and Server 2008) includes the Microsoft .NET Framework 3.0 (and 2.0) as an operating system component. If you are using .NET, make version 2.0 or 3.0 your requirement, and you will make my life easier. If you have another framework requirement, such as .NET 3.5 or Java Runtime Environment, follow the manufacturer's guidance for installation to the letter.
  2. If the software supports automatic updates, do you generally allow this?
    No. In a limited-user environment, users can't approve updates, and I almost never want program updates other than OS security updates to download automatically. Turn off automatic updates by default in quiet or basic UI installation modes, so that if I deploy via Group Policy, I don't have to then follow up with registry-modifying scripts or workstation visits to turn off your updater. In a manual, interactive installation, it is fine to prompt for this.
  3. How long does it generally take?
    I don't have a good answer for how long it takes. At my last job, it varied widely in the range of immediately to years.
  4. What kind of licensing models do you prefer (transferable, per-seat, per-CPU, site-wide)?
    Licensing needs to be easy and familiar. The more similar your product licensing is to something I already know, the less I have to learn about it, and the faster I can get on with purchasing and deploying your product. Depending on the kind of program, I tend to prefer per-machine or per-user licensing; these are easy to track by assigning them to specific users. For my previous job, our company was too small for what were usually very expensive site licenses to be affordable.
share|improve this answer
add comment

The function of IT is to deploy and maintain technology to support the core business.

To you, the ISV, that means:

  • Provide an automatable installation AND uninstallation process that is well tested
  • Integrate your update process with the systems management tools, if possible. If you have one or two offices with fast WAN/Internet connections, autoupdate is fine. For a place like where I work with over a thousand remote locations with bandwidth ranging from 56k Frame Relay to 1GB metro ethernet, we need to control when things happen.
  • When internal development groups or a business unit submit software for distribution, we're able to distribute that software in 3-5 days. Typically user acceptance testing takes the most time, and is entirely dependent on the testing process of the group we're dealing with. (The 24/7 system used in the callcenter has a formal testing process. Upgrading Dreamweaver is a very low-impact testing process)
  • If you're software is impossible to package in 3-5 days, you're losing points when we evaluate you. If your distribution model is really dumb and we have a choice, we'll disqualify you.
  • Document, document, document

Licensing is something that depends on what you do. As an IT guy. When you select a software solution for procurement, the licensing model needs to be part of that process. We cost license administration into our procurements, so if you're a company like Symantec that wants to nickel and dime us with 6 different license metrics, our compliance cost will count against you. If you're a company like Microsoft and your outrageous licensing process is awful, but I don't have a choice... then that just becomes part of the cost of doing business.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.