Posts tagged "licensing"

InDesign Server questions and answers

Customers often ask me about InDesign Server. InDesign Server? Yes, it’s true. InDesign is available as a server, which makes document automation possible for many kinds of businesses. It offers InDesign functions as a service, accessible through SOAP or other communication protocols. It is not the desktop version of InDesign available in a browser.

Companies have successfully used InDesign Server as part of workflows that:

  • Make greeting cards
  • Produce mutual fund documentation
  • Generate personalized mail pieces
  • Assemble and print on-board schedules on a cruise ship
  • Render InDesign documents as PDF for online delivery
  • Layout quarterly catalogs for industrial parts suppliers

These are but a few of the use cases for which InDesign Server is appropriate. In all cases, InDesign Server is part of a larger business process, usually driven by a web site or a Digital Asset Management (DAM) solution such as Adobe Experience Manager (AEM) Assets. InDesign Server is also included as a component of many commercial Variable Data Publishing (VDP) and Print on Demand (POD) solutions, but those servers are licensed only for use with those commercial solutions. You can learn more about InDesign Server partners at the InDesign Server Partner Guide.

InDesign Server is a service, really, that responds to questions like:

  • “Hey, InDesign Server. If I give you this InDesign template, can you merge this XML file onto it and then give me back a print-ready PDF?”
  • “Hey, InDesign Server. Here’s an InDesign Document. Can you extract all of the text frames as RTF files and re-link them back to their original frames and then save InDesign file as a new document with _relinked added to its name?”
  • “Hey, InDesign Server. Can you make a new document, import the style sheets from this other document, then import all of the images in this folder, each on a new page, and apply the object style ‘image’ to each image and put a metadata caption with the copyright data in the lower right hand corner of each image, and then export each page as a new PDF with the file name corresponding to the filename of the image placed onto it?”

Of course, those questions must be written as scripts in one of four languages: Adobe ExtendScript, JavaScript, AppleScript or Microsoft Visual Basic. AppleScript and VisualBasic are only available when the server is running in an Apple or Windows operating system, respectively. There is an SDK and many examples available at There’s really no limit to what you can do with InDesign Server, so long as you have coders who can ask the right questions and so long as you have enough capacity to process the volume of jobs you expect to handle. There are many companies who use InDesign server to build photo books and greeting cards from customer-supplied photos, for instance. They create web sites to help customers design their books and cards online, and the actual print-ready files are made by InDesign Server. They process thousands of jobs per day, so they need to have enough capacity to keep up with their demand. How, then, do you architect an InDesign Server application from the perspective of the servers themselves?

Here’s three questions you need to ask to help scope an InDesign Server application, and then some more detail about InDesign server.

  1. Will your use case allow internal and external users to access the InDesign Server directly? If you use InDesign Server to render an InDesign document as a jpg or pdf and then post the jpg or pdf on your web site, the end user does not have direct access to InDesign server. If you make a web form that lets your end user customize a document and deliver it to them on demand, they do have direct access to the InDesign server.
  2. What is your failover or disaster recovery requirement? The deployment architecture allows for both multiple dedicated servers as well as multiple instances on servers with multiple cores. The licensing will depend therefore on how you mix dedicated servers and instances on those servers.
    The deployment architecture will also depend on maximum expected throughput. We usually look at the peak demand per minute or quarter hour or hour, depending on the use case, as well as the end user tolerance for delay between requests and results.
  3. How do you plan to support development for InDesign Server applications? Deployments typically have one or more development instances, and then two or more dedicated production servers with multiple instances available on each server to provide fault tolerance.

InDesign Server is available as an add-on to a managed services instance of AEM. Customers can also purchase InDesign Server on their own from their channel partner or from Adobe directly, depending on their relationship with Adobe. 60-day Trials are available at

InDesign Server is licensed based on use case and deployment architecture, and it is available as an annual subscription like Creative Cloud. Enterprise customers can license in three year terms as part of an Adobe Enterprise Term Licensing Agreement (ETLA). Other customers can purchase annual subscriptions from their favorite Adobe reseller. Consult the Indesign Server Buying Guide for more information.

Across the use case axis, there is Limited and Premium.

  • Limited allows a customer to use InDesign Server for an application that only their employees can access. It does not allow the customer make an interface that exposes the InDesign Server to any external user. They would purchase Single- or Multiple-Instance licenses depending on how many documents they would process per day, hour or minute.
  • Premium allows a customer to use InDesign Server for an application that external users could access as well as internal users. Consider the photo book use case where they have a web site that allows customers to upload their photos and buy a photobook. The book is made using InDesign Server driven by a web application. Again, volume would determine whether you would choose Single- or Multiple-Instance licenses.

The deployment architecture axis has two options as well: Single-Instance or Multiple-Instance.

Single-Instance allows one instance of IDS per server per license, and Multiple-Instance allows multiple instances of IDS per server per license. There is no CPU counting required, as the Multiple-Instance license includes an unlimited number if instances on the same server hardware. For instance, if a customer has a 16 core dedicated server with 32 GB of RAM, they could use one IDS Multiple-Instance license and kick off 15 simultaneous instances of IDS at a time (InDesign Server is single-threaded and uses a single core per instance and ideally 2GB of RAM). Other customers choose to deploy many Single-Instance servers on different hardware for fault tolerance and disaster recovery. InDesign Sever has a job queue manager, but many customers choose to build their own queue manager and load balancer. Adobe Experience Manager includes an InDesign Server load balancer and queue manager as part of its integration with InDesign Server. Some customers choose to deploy many Single-Instance servers, while others choose to deploy few Multiple-Instance servers, based on their requirements and available server resources.

How do you decide whether to choose Single- or Multiple-Instance architecture? It is common for high volume use cases to have at a minimum of two Multiple-instance servers, each that can process multiple simultaneous jobs. Two servers provides for fault tolerance, but it does not account for disaster recovery, which would include another instance in a different data center. The number of servers is usually determined by the typical job characteristics measured in seconds to process a typical job, divided by the number of available instances, and compared against the maximum number of jobs that are expected to be processed in a meaningful time interval, usually one minute to an hour. If you are running a financial services company that is generating three hundred complex proposals per hour, and each proposal takes 15 seconds to process, and you have 3 cores available on your server, then your server can handle 3 jobs/15 seconds * 3600 seconds/hour =  720 jobs per hour. Since you need to process 300 jobs per hour, per proposal type, you have enough capacity. But, if you need to know if you can handle the volume at the end of the trading day, when you only have 15 minutes and not an hour to get the proposals out, then your server will fall short and you should likely add another server or two to the cluster.

The last consideration is how you plan to develop and test your applications. You should have at a minimum of one development server that matches your deployment configuration, and there is a Development license available with the same use case and architecture considerations. Developers use their development tools of choice. It is common to use the ExtendScript Toolkit, which is part of Creative Cloud. Using ExtendScript Toolkit, developers can connect to a desktop InDesign to test and debug their scripts. Once they are satisfied with the performance and results, those scripts would either be moved to the InDesign Server Scripts folder or would reside in the web application or DAM, which would send the scripts as part of their job payload.

InDesign Server offers customers document automation capabilities that can provide brand consistency, high volume document creation and even new business opportunities. Whether part of a commercial solution or part of a custom application, InDesign Server delivers performance, flexibility and quality to automated document processing.


Share on Facebook

Single Issue vs Multi Issue Viewers for Enterprise customers

DPS customers have access to tools for creating and managing custom versions of the Adobe Content Viewer that can be distributed through iTunes (like the Wired or National Geographic apps). Additionally, Enterprise DPS customers can build apps for private distribution using an MDM service like MobileIron or Air-Watch. Only Enterprise DPS customers can build apps for Enterprise distribution models, and I have provided an earlier post about that process.

One of the options for the custom viewer is a Single Issue Viewer, in which one folio is embedded directly into the viewer. Single Issue Viewers have no library mode, so they are used by many of our customers who want to use MDM solutions to manage the distribution of specific folios to specific people. However, we have other customers who use MDM to distribute Multi-Issue Viewers to their managed devices, and then use our Restricted Distribution infrastructure to leverage LDAP or other authentication to control access to specific folios in that one viewer app. There are IT advantages to either approach, and I’d like to explore the differences.

In order to use an MDM system to manage apps on an iOS device, each app needs to be created using a specific unique identifier known as a mobileprovision file. Customers make these in the iOS Provisioning Portal, which is part of Apple’s iOS Developer Portal. In the Single Issue approach, each Single Issue Viewer needs a new, unique mobileprovision file from the iOS Provisioning portal. MDM solutions leverage a property of iOS whereby each app must have its corresponding mobileprovision file on the device in order for the app to run. MDM solutions can remove a mobileprovision file on a managed device, rendering the app unusable. When a customer makes a new Single Issue viewer, it must repackage this app to include the new, unique mobileprovision file in a process called resigning. There are several ways to do this, but a popular method is to use iresign from Google. This workflow is very effective because it gives IT fingertip control over each and every app on a managed device, and it allows IT to move DPS Folios in and out of circulation by wrapping them in Single Issue Viewers.

Let’s face it, though. Managing all those apps and mobileprovision files is annoying IT overhead. In the Multi-Issue approach, there is only one mobileprovision file because there is only one Viewer. Content delivery to the Viewer’s Library is based on credentials and is managed by a business user, not IT. The business user can associate content to users or groups in a portal without having to call IT to issue a new mobileprovision file. This portal can be built and managed by corporate IT using sample code from our Developer Center. Derek Lu, for instance, provides detailed instructions and sample code for integrating LDAP with Restricted Distribution. There are also commercially available servers such as Portico from MEI to enable Restricted Distribution workflows in an Enterprise without IT having to develop a backend solution from scratch.

Which method is right for your company? That depends on how you want to manage content. If you want IT to manage everything, then the Single Issue approach might be just what you need for DPS. If you want to reduce the burden on IT and shift content management over to the business users who file the IT tickets in the first place, then Multi-Issue with Restricted Distribution fills the bill. DPS is flexible: your designers create their engaging tablet content in InDesign, IT puts the apps on the devices, and either IT or business users manage the flow of those folios to users. Either way, you can use your MDM system to manage DPS viewers on your company’s tablets.

Share on Facebook