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

Coming from the software provider side (never really having to deploy my own product further than a few test machines) I find myself lacking knowledge of the 'standard' or 'available' tools that administrators might make use of to re brand a piece of software and what effects that has on deployment.

By 're brand' I mean changing the UI so that it appears with company specific information such as imagaes, about etc. It might even be considered akin to localising (but I'd expect with less text).

Would you want to brand the installation process itself, or just the final product?

If only the final product, is it acceptable to run a seperate distribution step to apply the branding or should it be included in the install?

Do you have an existing process and tools to re brand? - like installing msi to clean machine, applying branding, capturing changes and rebundling a custom msi

How would you manage changes between versions of the product?

  • rebrand from scratch,
  • keep some 'diff' process
  • ...

What formats are easier to work with?

  • resource.dll,
  • resource.jar,
  • 'bunch o files'
  • ...

Considering different deployment scenarios, would there be any difference between

  • Server product, maybe multiple servers
  • User desktop product
  • Server product that also acts as distribution point for desktop product (like JNLP, msi, plugin)
  • ...

What other pain do software providers put you through in a corporate environment when deploying software with your brand on it? What questions didn't I know to ask?

share|improve this question
1  
How do you figure this software packaging is an administrator's job? It has absolutely NOTHING to do with systems administration. If anything it's bordering on being a developer's job. –  John Gardeniers Oct 22 '10 at 1:24
    
@John Gardeniers: Software packaging, in the context of packaging third-party software for deployment to large numbers of client computers is certainly something that falls under my job description pretty frequently. (I'd love it if it didn't, though.) I think the OP is going more for the "MSP" market of outsourced sysadmins, personally. Having said that, substituting the words "your customized configuration" for "branding" make it a very viable question to me. (I think I'll edit my answer, actually, and put that in...) –  Evan Anderson Oct 22 '10 at 2:30
    
@John Gardeniers: I was thinking system administration as in managing package installation within an IT environment, procedures for doing so. Maybe the question would have been better on stackoverflow, but I was after the admin perspective. I'll take from your comment - don't need this feature, wouldn't touch it. –  Greg Domjan Oct 22 '10 at 18:25

1 Answer 1

A little soapbox first: Personally, I don't see any advantage to "branding". If my company didn't write the software I don't consider it a "badge of honor" to stick my name on that software seeing as how, when there are problems with it I won't actually be able to solve them. You're addressing this to sysadmins but, perhaps, you're thinking more about a "Managed Service Provider" audience (who seem to just eat up this kind of stuff. I'm thinking about the various outsorced backup companies, for example, who let their "partners" slap a logo over top of the actual provider's name...)

If I substitute the words "customized configuration" in place of "branding" I find that your query is very pertinent to the type of work I do preparing third-party software for deployment to PCs and servers in my Customer sites. (I'd love it, personally, if the third parties would just start using Windows Installer and quit it w/ the custom SETUP.EXE deployments... GRR!)

All that aside, to address your specific questions:

Would you want to brand the installation process itself, or just the final product?

and

If only the final product, is it acceptable to run a seperate distribution step to apply the branding or should it be included in the install?

I'd perfer to see branding added after a "stock" installation of the "final product". That gives me an option to always install a "stock" distribution and to revise the "branding" resources separately from the software itself. Something applied after-the-fact would be good.

With MSI-based setups, for example, I see applying a transform file (MST) as being a modification to the "stock" deployment, but I always have the option to "fall back" to the stock deployment if I want to be sure that my "branding" isn't causing a problem.

How would you manage changes between versions of the product?

Ideally you'd maintain backwards-compatibility with prior branding resources such that the same "branding" process would work for future versions (failing gracefully when the older versions of branding resources don't have values specified for future branding mechanisms). I'd maintain the branding resources in version control like I do with configuration files, MSI transforms, etc.

What formats are easier to work with?

Executible binaries pose potential problems in a Windows "AppLocker" environment where they might need to be signed. I'd prefer that the branding be kept in a non-executible file. A JAR file (a ZIP file, basically) would be fine, as would "bunch o' files".

Considering different deployment scenarios, would there be any difference between
  • Server product, maybe multiple servers and User desktop product - These would be installed via Group Policy Software Installation Policy or startup scripts, so there's no difference. Ideally, the branding step could be as simple as installing an addt'l MSI that puts a "magic file" (or magic "bunch o' files") in the right place and the branding "just happens".

  • Server product that also acts as distribution point for desktop product (like JNLP, msi, plugin) - I don't use products like that, because I don't allow users to install software. If I were going to do something like that I suppose I'd have the product installer access a defined DNS name in the local DNS zone via HTTP (HTTPS, etc) to download the branding from a defined file name (think "http://productname-branding.yourdomain.com/branding.zip"). Then distributing the branding would be a matter of putting the branding file(s) up on a web server.

What other pain do software providers put you through in a corporate environment when deploying software with your brand on it?

I've never had the opportunity to "brand" any software, so I can't say.

In thinking about "customized configuration" as opposed to "branding", having comprehensive documentation about the configurable features, as Chris S says, is a good thing. Very rarely have I run into products that do a good enough job describing their various configuration mechanisms and how to manipulate them (other than through the UI). Personally, I think that any UI configuration interface should have a "supported" method of programmatic manipulation w/o requiring any user interaction, as well. I don't necessarily need to know about your various opaque binary configuration data repositories, but I want good interfaces to let me maniuplate the configuration from a script / installer, etc.

I think you're really targeting this question more at the type of Sysadmin who fancies themself a "Managed Service Provider" (MSP). In such a situation everything I'm saying above is probably wrong. An MSP would probably want branding to be integrated directly into an installer such that they could hand out the EXE, MSI, etc, to their Customers and the branding would occur "magically" during the installation.

From a the perspective of being a Customer for an MSP who was using software like this all I'd ask is to give me an automated way to install and uninstall your product in a determinstic and reliable way and I'd be happy.

share|improve this answer
    
The only thing I would add: "What other pain do software providers put you through" - Documentation! Sure it's nice if you have the same process each time. But for goodness sakes, write a document titled 'Branding [Program]' with good procedures and include it with the standard documentation. –  Chris S Oct 21 '10 at 22:40
    
Thanks Evan, appreciate the time you put into answering. I think this highlighted to me there is likely a different focus in branding for an MSP onsale and for end consumer. We do more of the 'end consumer' focus right now, but ideally one solution to cover both. MSI/MSP + MST seams like the current method of choice then on windows, regardless of if it comes right from me or the case of onsale from an MSP. –  Greg Domjan Oct 22 '10 at 18:01

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.