Free Tools for Building Multi-format Documentation: See Our Article in EE Times

Concerned about vendor costs when it comes to producing technical documentation for the web? You might want to take a look at our recent article in EE Times reprinted below. (See the original article at

Using open source tools, it’s possible to create a documentation system that can present the same information on large and small displays.

In a recent column on, Max Maxfield blasted the slapdash guide that accompanied a module he’d purchased and asked why so many manufacturers neglect documentation until the last minute (see Basic documentation—is it too much to ask for?). Was a budget or staff ever too big to blame for procrastination? Yet even a conscientious development team can’t supply useful help without a well-organized system in place to record work in progress, edit the information, and publish documentation in whatever formats are required for easy access. There are many ways to build such a system based on commercial software, which can be expensive, or by using free and open-source tools.

My firm has generated documentation for more than 30 years for semiconductor fabrication equipment, graphics processors, test instruments, network gear, CAE tools, and so forth. We’ve rescued clients on the brink of product rollout and worked on multiyear projects from the inception. The best path for any manufacturer, whether a startup or an established enterprise, is—before product development begins—to put in place internally a documentation system tailored to deliver information in ways most convenient to customers. Let’s consider a straightforward, low-cost approach one company used to get up and running quickly.

Content from PDF (background) scaled for display on cell phone

A long-established manufacturer that produces biomedical instruments and related assays for disease screening sought a documentation system that could output product literature in both PDF and in HTML format for Web presentation from the same source text. The company had built an extensive library of instrument manuals and detailed guides for its many assays, all of which had been produced using the Adobe page-layout tool, FrameMaker, and needed a flexible platform for generating searchable new documents for electronic display that would be virtually identical to their print counterparts. The content, as well as the structure of any of the documents in either format, requires FDA approval subject to stringent federal review.

The project was fast-tracked by a battery-backed portable instrument that was in development. This instrument tests biological samples in the field to quickly determine whether patients have HIV, certain influenza strains, or other infectious diseases. It is intended for use at remote sites and in neighborhood clinics, especially in developing nations, where there may be limited electrical power and economy is paramount. The user interface is a cell phone controlled by a dedicated application, unlike other instruments made by the company, which communicate with a laptop or desktop computer.

Instructions for operating the instrument, as well as the guides for the assays it runs, reside in the cell phone, except for brief startup steps on paper to turn on the phone and open the app. Assay guides run 30 to 40 pages in PDF, posing a challenge how to present the material legibly on a display that is less than six inches long by three inches wide in a structure that could be easily searched.

An open-source standard, DITA (short for Darwin Information Typing Architecture), was chosen as the foundation for the documentation system. DITA, which was originated by IBM, defines an XML architecture for publishing information in multiple formats for print, Web display, and retrieval on mobile devices. Document outputs in the various formats are implemented using the DITA Open Toolkit, a collection of open-source software programs. The upshot of DITA is that content is distinct and independent of how it will be presented, with reordering and reuse in mind.

Some existing assay guides had to be translated from PDF for use with the portable instrument. The content was extracted in essentially a cut-and-paste operation and then tagged in a DITA XML markup. Formatting templates were created so the documentation system would strictly adhere to the FDA-approved style for the company’s literature in PDF, and then the toolkit was used to output files in HTML5. The toolkit can render DITA XML files for output in several formats, including XHTML, HTML5, PDF, and others. Although FrameMaker, the page-layout program, also can export files in HTML, it would actually complicate building a Web portal for documentation: you can’t make inter-document links, for example, or readily create a hierarchy for building a documentation site.

Arranging the HTML5 output from the documentation system for display on the cell-phone screen involved Bootstrap, a framework for automatically scaling websites for viewing on phones, to tablets, to desktop computers. Bootstrap, which is a collection of cascading style sheets and JavaScript, employs a grid for defining how information should appear within different screen dimensions. For a large 4k display, for example, content could be presented in multiple columns, if desired; for smaller screens, how elements shrink, are rearranged, or remain visible can be defined.

In the case of the project we are discussing, content is displayed in a two-column makeup on a widescreen, and in one column on the cell phone with a collapsible table of contents at the top. For the phone, each document section amounts to a Web page. Information is displayed one section at a time. There is always a table of contents that can be expanded for quick and easy navigation through the document. If the table of contents is collapsed, the material for one section is displayed and—when read to the bottom—there is a link to go to the next or previous sections.

During the development of this system, a technical detail tied to regulatory acceptance arose that had to be resolved. When documents are authored in FrameMaker, tables that continue from one PDF page to the next repeat the table title. However, the PDF outputs yielded by the DITA process don’t repeat table titles from one page to the next—just the table headers.

Another tricky issue, general in nature, was how figures are numbered in the HTML5 output from the DITA toolkit. The PDF output is fundamentally a continuous scroll, but the HTML5 output is broken up into sections and the toolkit does not number figures in succession but starts again from 1 in each section. The fix involves adapting a bit of code from the PDF process. Basically, the PDF process produces a file that merges topics mapped in DITA, but HTML documents are collected assemblies of the topics, each of which remain in a separate file. The PDF process merges everything from the DITA map, everything from the document hierarchy, rolled into one big file that is used to count such things as figures. The code that was appropriated from the PDF process modifies the HTML process to maintain the consecutive numbering of figures.

Any plaintext editor can be used at the front end of such a system to create content, though a modest investment for Oxygen, XMetaL, or other commercial XML editor is worthwhile. Those programs are much less expensive than FrameMaker, which is the conventional workhorse for document creation.

Startups, especially, who want to build a flexible documentation system quickly and inexpensively that can publish material in multiple formats from the same content can benefit from this approach, which is based on free and open-source software tools. The only problem remaining, therefore, is procrastination.

Building an Economical, Web-based Documentation System

A client who provides a web proxy service to shield enterprise customers from malware recently hired us to build a documentation system we had proposed to quickly produce content for web presentation. Draft text is shared, edited, coupled to graphics, and automatically tailored for export straight to the web in a smooth, secure process based on free and open-source tools.

The company as a proxy executes customers’ web sessions, removing Flash and other active elements that might contain threats, and then relays the sanitized results to the customers, all without perceptible delay. Their customers need clear instructions for installing the service but when the company approached us, the documentation at hand was a mix of PDFs, Word texts, and a few procedures online, all in need of a thorough technical edit and consistent style and branding. We converted the existing documentation so it would be clearly legible on the company website and structured a system for creating new documents that could be easily uploaded to the website and displayed in any screen format with no need for conversion. We had in mind an infrastructure that would be easy to maintain.

First, we converted the existing documents to plain text and then we used Markdown, a simple mark-up language that provides a syntax for plain-text formatting, to generate the typographic conventions for headings, italics, bold type, numbered lists, unordered lists, and so forth. Moving forward, we developed a consistent style in which documents would appear on the website.

Easy to implement

We based the documentation system on a static-site generator—Jekyll–which takes the plain-text files in Markdown, organizes those according to templates we created for text and style, and creates web pages and a navigation hierarchy. Simply run a command and the system produces a directory of files for upload to the web server and the process is complete.

Jekyll is an open-source static-site generator that was intended for blogs as an alternative to WordPress, which was becoming complicated, cumbersome, and involved managing a back-end database. It is extremely easy to use. Features that make it helpful for blogs also make it a very convenient engine for a documentation system. For example, it can automatically create lists of all the blog posts from an author in reverse chronological order and create tags so posts about a particular subject can be collected on one page. We leveraged Jekyll because it thereby enabled building an organizational framework for the documentation system, not only style templates. For fast website deployment, security, and limiting infrastructure maintenance, we decided a static-site generator would best serve the application.

The workflow is streamlined for document generation and deployment.

Streamlined workflow 

Once we converted the existing documents to plain text, we put them into a private repository on the website to share and collaborate with the client’s staff. The Github website is based on Git; a version-control system that can pull from many servers. Everyone given company access has their own version of the entire private repository, enabling the staff to work on the files and see each other’s changes.

The client’s chief of publications produced raw content adding to the work we had done, and then we did a technical edit of the new material and submitted changes to him, in an informal ongoing process. However, based on Github, the structure is in place to implement a formal process for merging changes from authors, who can make technical edits and then submit a pull request: I’ve made this change; do you want to accept this into the main branch?

Beyond version control, Github gives a preview of how documents will look. Simply upload a Markdown file with accompanying images and Github melds into order the text and graphics free from compositing symbols. The publication chief can confirm how pages would be organized, set the layout with the Jekyll templates, and commit the results for upload to the company website.

The benefit of using plain text for generating documents, instead of such programs as Framemaker or Word, is that you can tap into the decades of development founded on plain text; namely, all the sophisticated tools that can analyze two very different versions of a text, see where they differ, automatically merge changes, and identify where a conflict must be resolved.

There is some downside of working in plain text, at least for engineers who are documenting product designs in progress. Composing in plain text is not as familiar as writing in Word. However, making the transition from Word to composing in plain text is not especially onerous.

Given the simplicity, convenience, and low cost of using this combination of free and open-source software to build a flexible and robust online documentation system, the approach can benefit many ventures, especially startups who have limited IT resources, small budgets, and pressing calendars.

Writing for Enterprise Mobile Apps

Building a New Publishing Process While Developing Content for a Future Product Release

We recently completed the first phase in a significant new project. It required designing, building and implementing a new documentation process, while at the same time developing content for three new products.

Our client builds mobile application software development tools. They were looking for a tech writing company that also could make their documentation process more agile and productive.

The process they were using relied on structured FrameMaker which then was converted to HTML and PDF files. But they found this slow, hard to manage, and outdated. Our role was to design a new content development and workflow process and to assist in its implementation.

At the same time our tech writers would be working with their software developers, who are located at different regional centers. We would have to develop a working relationship with remote experts and collect, develop, update, and publish content in a timely manner.

The group assigned to the document publishing process set about exploring different publishing processes. The group assigned to developing content immediately started working with the subject matter experts.

The Publishing Process

To start, we examined several options for publishing content to the web. These included Python, Sphinx, DocBook, Slate, and others. We built demo sites to show their look and feel. And we evaluated their ease of use,  their output templates, their suitability for the client’s resources and processes, and their scalability.

As a software development company, the client was already using Atlassian’s enterprise software tools for issue tracking and team collaboration. The Developers, our subject matter experts, were comfortable working within Confluence, the Atlassian wiki, to document the products. And Confluence uses a REST API, so the wiki could be queried and content pulled from it.

We realized that if we could continue using that wiki, the Developers would be much more responsive in delivering the content we needed. We also could use JIRA, the Atlassian issue tracking tool, to monitor issues blocking content development.

The goal then became to build a process that used the wiki and integrated seamlessly into their workflow. The result would allow the client to be in complete control of the process, without having to learn any new technologies or tools.

However, important issues remained to be solved.

Because they had in-house NodeJS resources, we proposed using DocPad as the interface to pull the content from the wiki. To get this to work, we built a special DocPad plug-in to automate the query and pull the content from the wiki. The content was rendered to templates built for customer-facing content and then deployed to their AWS servers.

The following screenshots show the content as developed in the Confluence wiki and the output as it appears on the company’s web site. Changes made on the wiki can be scheduled to appear on the web site whenever you want.

Confluence wiki page Public-facing content
Image1 Image2

So what does this mean for you? First, we listened to what the client wanted. We worked with them to determine the best approach to the problem, and we made maximum use of their in-house resources. The result was a process that they completely control. At any time, anyone in the company can view the current status of the content …. There’s no hiding, so you’ll always know if the content will be ready with the product at release time. And when it’s ready for release, it can be pushed to the web site and packaged with the product build as part of the SDK. Fast …. Easy!

By the way, if you’re interested in the DocPad plug-in, you can get it at NPM (Node Package Manager):


Developing Document Content

Of course, what good is a process if you don’t have content to publish? The first issue the tech writers had to resolve was developing a working relationship with subject matter experts located in three geographical regions. Site visits could be made to the local office, but video conferencing tools were needed for remote sites. Two that we found useful were Google+ Hangouts and by LogMeIn, Inc.

Working with the subject matter experts, the tech writer created wiki pages for the product content. Links to those pages then were sent to the subject matter experts so that they could write, review, and correct content. The “Watch” feature in Confluence alerted participants to any changes; the “Talk” plug-in was used for contextual Q&A exchanges. The tech writers ensured that the content was written with a consistent editorial style, that it fit within the overall organization of the material, and that there was a smooth narrative throughout.

During the development process, the wiki content was published to an internal review site so that anyone with authorization could see what it would look like when published to the web site. This was important because the template for the public-facing content is branded differently from that displayed in the wiki.

Document control was handled using Comala, the Atlassian workflow product. This ensured that the content went through the company approval process before being released to the web site.

So how did this work out for the client? They were never in doubt as to the availability of the documentation when it came to product release. And those last minute changes that came in were no problem at all.

We’ve Moved!

That’s right, it was time to make some improvements. After so many years in our last location, and a major project behind us, it was time to freshen things up.

Our offices now have a bright new appearance overlooking Willow Glen’s bustling Lincoln Avenue. And it’s not just about the new look. We’ve also upgraded all our office systems, including our file sharing services, our phone and internet systems, and our computer network. Our data speeds now are faster than ever, and our security meets the highest standards.

Of course all this had to happen while work continued without interruption. So a strong Thank You! to the Staff for your perseverance during the change. And a hearty Welcome! to our Clients. Drop by anytime and see the change. I’m sure you’ll like it.

Keeping business operations going while the new office is being preparedImage1aImage1b




Wiring the new office space with gigabit Ethernet and a fiber Internet connection.Image2b








This is as clean as it will ever look. Nothing like a new space.Image3a Image3b

 We’ve arrived! Welcome to our new location. Drop by and say hello.Image4a

HTML5: The Future of Content Management on the Web Is Here

Content is growing in volume, complexity and diversity – by next year – 2015 – the forecast is  7Bn devices will have an IP address – and 5.5Bn people will be on the internet on (Apple, Android and Windows) platforms. The tools companies have deployed for content management are failing to meet changing mobile user needs. BYOD/mobility has broken HTML4 .. So W3C – which exists to realize the full potential of the Web – jumped in and we got HTML5. It’s now a candidate recommendation, which means the features are locked but W3C are looking for feedback from implementers..

Tech Pubs: Stuck with a Bucket of PDFs?

For years, technical documentation has been developed using word processing or page layout tools, such as MS-Word, FrameMaker, Quark, and InDesign. The output is a book-length document, typically released as a PDF, designed to be read front to back. But PDFs have significant limitations, both to your customer as well as to your sales and marketing groups.

Typically, customers don’t first read the technical documentation cover to cover and then use the product. They rather refer to the documentation when they are looking for an answer to a problem they’ve encountered with your product or technology. More often than not, they’ll start by searching the web for an answer. With luck, the PDF appears among the first in the list of search returns. But that’s left up to the Google search algorithm, which is not something you can control.

Then the PDF must be opened for the content to be viewed. This requires opening a separate Acrobat Reader application or a browser plug-in, which can take time. You can optimize a PDF to reduce its file size. But if the document is very long, or it includes heavy use of artwork, it can be slow to open.

Then the user must repeat the search within the PDF. If the answer isn’t in that PDF, then the search process must be repeated. You can hope they find an answer quickly. Or you risk an unhappy customer.  And customer satisfaction affects future sales.

Then there is the static nature of PDFs. While considerable resources may have been required to develop the content, that content is not easily shared throughout the company. Worse, you lose significant valuable information regarding customer use and feedback. And that’s another hit to your sales and marketing groups.

So what’s the option? Use the tools that optimize documentation for the web. XML is the document markup language for the internet.  XML documentation output can be a web page, as well as a PDF. Documentation produced in XML has powerful capabilities, including:

  • Faster access. Technical information is presented in smaller “chunks,” produced and displayed using native internet and web-based tools.  Not only is it more quickly accessed by the user, it’s also easily edited by authorized users.
  • Automated formatting. Most markup languages use separate stylesheets to format the output, such as CSS and XSL-FO. These define the corporate tech pubs style guide. Once these files are created, formatting is automatically applied across all XML content files. Content development moves much more quickly and freely.
  • Web analytics. It’s now possible to learn how your customers use the content you provide. This can be of huge value in identifying the strengths and weaknesses in the material. It also can improve the product.
  • Customer feed-back loops. Great products still require careful attention to customer satisfaction. It’s now possible to set up your documentation system so that customers can respond with their comments, questions, and suggestions. This enhances the customer experience, a critical factor in sales and marketing.
  • Version tracking. Because XML document files become part of your source code or content management system, it’s much easier to follow the evolution of the content. Between the first draft and the last, did something critical get lost or misrepresented? Simply search the earlier versions.
  • Shared content: At its most basic, every document contains copyright and contact information. If information changes, each of your documents must be updated. Who has time to go back and update PDFs? With XML content, this information can be maintained in a single file. Update that file, and you’ve updated all of your content.
  • Collaborative development. The internet is a powerful collaborative and social tool. Because formatting is left to the stylesheets, authorized users can participate directly in the documentation process using a simple text editor. Using version control, tech writers and editors can see what changed.
  • Access control. Access to content is more easily controlled. For example, user content can be more easily distinguished from System Administrator or Developer content. There is no longer a need to produce separate PDF documents.

There are a number of options for implementing web-based documentation. Choosing an implementation depends on the nature of the content, the version control/content management system available for organizing and tracking the content, and the desired output.  The more popular implementations are:

  • DITA. This is more amenable to the specialization/definition of information/content architecture. It is better for massive collections of interrelated topics.
  • DocBook. This was originally intended as a way to manage single books or articles. It’s better for projects that focus on a single large publication.
  • CMS/Wiki. This allows collaboration on multiple unstructured content.

Interested in learning more? See our blogs An Introduction to XML and DITA, Technical Documentation Moves Toward Live Product Content, and Editing Equations in Oxygen XML Editor for more information.

Jim is the owner of Phoenix Technical Publications. Phoenix Tech Pubs has provided complete technical writing and documentation services in Oakland and the San Francisco Bay Area for over 25 years.

Editing Equations in Oxygen XML Editor

Editing equations in Oxygen XML Editor version 14.0 was more difficult than we expected. After trying several of the leading MathML editors, we found a versatile, easy-to-use, inexpensive solution.

Oxygen XML Fragment Editor

The Help Pages of Oxygen XML Editor version 14.0 have this to say about its support for equations:

“… includes a built-in editor for MathML notations. To start the MathML editor either double click a MathML notation or select the Edit Equation action from its contextual menu. In the MathML editor you are able to edit the mathematical symbols of a MathML notation.”

Either action opens the XML Fragment Editor window. A few problems with using this tool will surprise the user:

  1. WYSIWYG tools for entering new equations are not available.

MathML is not intended to be written or edited directly; an important reason all XML editors include a wysiwyg editing mode for MathML. This mode in Oxygen is called Authoring and is selected using the Author tab. While in Authoring mode, an equation is inserted by selecting Dita->Insert-> Insert Equation from the contextual menu. This action opens the XML Fragment Editor window with the Pythagorean equation as its default. The MathML code that implements this equation is displayed directly below the equation (see the example below). Note that there are no controls or menus in the window for rewriting the equation.

2. It is difficult, if not impractical, to edit equations using its wysiwyg feature.

The red box enclosing the equation is the only hint of possible wysiwyg editing capability. You can point-and-click on a component of this equation so the red box surrounds it and then make a simple change in code below it. For example, you can select each “squared” term and change it to “cubed”. Or you can change the “+” to “-“. But you cannot insert complex operators.

3. Although the bottom half of the window allows editing an equation via its MathML code, the code quickly becomes intractable as expressions become more complex.

The MathML displayed in the XML Fragment Editor window is the same non-wysiwyg view as would be seen if you had selected the Text tab. The user could, in theory, enter a new equation by making changes to the default equation in Text mode. But, as has been said, MathML is not intended to be written or edited directly. The complexity of the code just for the default equation makes this apparent. Also, you can also see the difficulty of locating components to make even simple edits in an existing complex equation that someone else has entered into the document, as shown  in the screen capture below.

Because we found the Oxygen XML Fragment Editor impractical for editing MathML, we researched other MathML editing options.


The makers of Oxygen XML Editor recommend the MathFlow plugin from Design Science for a fully functional MathML authoring tool.  The interface is easy to use and familiar to anyone who has entered equations in MSWord. However, the MathFlow plugin was incompatible with our client’s specialized build routine to output pdf and html failed, making the tool unusable for us.

Web Equation

At the Web Equation web-site (, an equation can be moused onto a grid, like drawing onto legal pad (see below). A print-quality image of the equation is rendered below the grid, to confirm the moused input. The MathML code is displayed by clicking on the MathML tab. This code can then be copied from the web-site and pasted directly into the XML document while in Text mode. Or it can be pasted into the document while in Authoring mode via the XML Fragment Editor window. However, with either method, our XML schema requires “m:” prefixes that are missing from the code supplied by Web Equation. For example, <mrow> and </mrow> tags should be <m:mrow> and </m:mrow>. To solve this problem as efficiently as possible, we copied the code into Notepad, used Notepad’s Find/Replace function to replace all instances of <m and </m with <m:m and </m:m, then copied-pasted this result into the XML document.

We found Web Equation to be of limited use, not just because of the extra step needed to add element prefixes, but also because many attempts were needed before the rendered equation was correct.

Mathematics StackExchange

Mathematics StackExchange is a mathematics question and answer website ( We searched and found summation equations similar to what we wanted. The MathML code for any equation at that website can be displayed by right-clicking the equation. Then the code is entered into the XML document using the same steps as described for Web Equation. Of course, because it is unlikely that any of the equations available at Mathematics StackExchange will be an exact match to what is needed, editing is generally required, which is a non-trivial effort using either Notepad or the Oxygen editor.


MathType, also from Design Science, has the same user-friendly interface as MathFlow and its MathML coding includes compatible namespace prefixes. The user enters the equation using a complete set of mathematic operators and templates displayed at the top of the MathType window, then only has to copy the equation rendered in the window and paste directly into the XML document. Our build routine worked perfectly. We chose MathType  as our primary MathML editor because it provides all the functionality we need and, because it is not a plugin, doesn’t break the Oxygen editor.

Grandy is a senior technical writer at Phoenix Technical Publications. Phoenix Tech Pubs has provided complete technical writing and documentation services in Oakland and the San Francisco Bay Area for over 25 years.



MSDSs for Cepheid

Phoenix Technical Publications has created a number of MSDSs and Product Inserts, including translations, for Cepheid, a leading molecular diagnostics company dedicated to improving healthcare by developing, manufacturing, and marketing accurate yet easy-to-use molecular systems and tests. An image of  the Cepheid Xpert FII & FII Assay MSDS is below. Follow the link here to the full MSDS. A complete list of Cepheid MSDSs is available here.

Cepheid Part Number 301-0876 Rev B – Xpert FII_FV MSDS


MaaS360 Extends Microsoft 365 and Exchange Online

As we discussed in our blog “BYOD and FIYS – The Consumerization of IT,” the use of personal mobile devices for work is becoming ubiquitous. Microsoft 365 offers cloud-based access to Microsoft Office email, calendars, Word, Excel, Powerpoint, instant messaging, conferencing, and file sharing across all major mobile platforms. Microsoft Exchange Online provides integration and synchronization of Microsoft 365 with mobile devices. However, Exchange Online does not provide all of the security features required for complete Mobile Device Managment (MDM). Fiberlink’s MaaS360 is the leading enterprise-class mobility platform implementing MDM as a cloud-based service. Using MaaS360 with Exchange Online expands the overall capability of Office 365 while  minimizing security risks.

The text below is from the white paper “MaaS360 and Microsoft Exchange Online with Office 365” which Phoenix Techpubs wrote for Fiberlink. Follow the link here to see the fully-formatted version at

MaaS360 and Microsoft Exchange Online with Office 365


Mobile devices and applications are permeating every aspect of the business environment.  Employees from CEOs to admins are using smart phones, tablets, and apps in blended activities like web browsing, personal email, corporate communications, and business productivity. Many are using personal devices to access the corporate infrastructure. IT
departments need to integrate all of these diverse devices into the enterprise with the ability to enforce privacy, security, and compliance while reducing costs.

When you combine MaaS360 with Microsoft Exchange Online integrated with Office 365, you get an affordable, comprehensive solution with fast deployment and effortless scalability.

The Essential Components for Managing Devices Connecting to Office 365

  • Selective Wipe, Lock and Unlock Actions
  • Tracking of Network Information
  • Seamless Device Remediation
  • Robust Auditing and Reporting
  • Mobile Application Management (MAM)
  • Single View of All Devices

Using MaaS360 for Mobile Device Management (MDM)

MDM software secures, monitors, manages and supports mobile devices deployed across enterprises. It typically includes over-the-air (OTA) distribution of applications, data and configuration settings for all types of mobile devices, both company- and employee-owned.

Using MDM, individuals can manage their own devices, minimizing IT involvement. Intelligent mobile device management can greatly reduce support costs and
business risks.

MaaS360 is the leading enterprise-class mobility platform implementing MDM as a cloud-based service. It provides fast deployment, effortless scalability, automatic upgrades and unmatched affordability, supporting all OS platforms and device types.

MaaS360 Extends Exchange Online

MaaS360 improves and extends the benefits of Exchange Online.
Exchange Online provides superior access and synchronization of corporate email, contacts, calendars, and tasks to mobile devices.

Using MaaS360 with Exchange Online expands overall capability and minimizes security risks. MaaS360 adds the following features to Exchange:

  • Single view of all devices syncing email
  • Automatic compliance enforcement
  • Selective wipe, lock and unlock actions
  • Device-level view of installed apps, jailbroken or routed status and location
  • Tracking of network information such as roaming status, real-time data usage and SIMs

MaaS360 Adds Mobile Application Management (MAM) to Exchange Online

MAM manages the purchase, distribution and update of mobile apps at the corporate and device level. MAM simplifies app integration deployment across the enterprise, while maintaining security and compliance.

MaaS360 not only integrates MDM in the cloud, but provides a comprehensive, integrated MAM solution as well, adding the ability to:

  • Centralize purchasing of apps
  • Distribute public and in-house apps across the enterprise
  • Manage app security and compliance across all users and devices

Securely Share and Manage Documents on Mobile Devices

MaaS360 simplifies and secures the delivery of documents to mobile devices by providing an easy-to-use enterprise document catalog giving administrators the control they need and employees the access they demand. The MaaS60 platform includes:

  • Enterprise document catalogs for iOS and Android devices
  • Web-based management consoleDocument lifecycle management
  • Document-specific sharing restrictions
  • MaaS360 Doc Cloud

For the administrator, MaaS360 provides indepth reporting on documents, users and devices to monitor status and usage for compliance and operational reviews. With a few mouse clicks, IT can upload, distribute and review distribution stats on any corporate document. IT can also make sure distributed documents are not forwarded, on a caseby-
case basis.

Users are alerted when new or updated content appears in their Doc Catalog without having to manually and continuously check for updates. The Doc Catalog allows users to browse and view documents in the most common content formats, as well as PDF,
web, video, image and audio files.

Integrating MaaS360 with ExchangeOnline

Integrating MaaS360 with Exchange Online is a surprisingly quick and easy task. Within minutes, an administrator sees all connected mobile devices and begins to manage them with MaaS360.

Technical Requirements

Integrating MaaS360 with Exchange Online requires:

  • Windows PC or Server with Cloud Extender
  • Windows XP, 7, Server 2003 or Server 2008
  • Microsoft .Net 3.5
  • PowerShell 2.0
  • Network
  • HTTPS outbound to
  • HTTPS outbound to Maas360
  • Office 365 Administrator account

Secure integration between MaaS360 and Exchange Online is handled by the Cloud Extender. A small program that runs as a service on a Microsoft Windows machine, the Cloud Extender provides the link between enterprise services and MaaS360, including
Exchange Online, Active Directory and more.


Installation is quick and easy. Install the Cloud Extender. The Configuration Wizard appears.

Check the Microsoft Exchange ActiveSync Manager service box and select Office 365. Click Next.

The wizard verifies that PowerShell 2.0 is installed. Click Next.

Enter your administrator account information so the Cloud Extender can connect to Office 365. Click Next, and then Finish to complete the set up of the Cloud Extender.

That’s it! MaaS360 is now integrated with Exchange Online.

For More Information visit
1787 Sentry Parkway West, Building 18, Suite 200 | Blue Bell, PA 19422
Phone 215.664.1600 | Fax 215.664.1601 |

Andrea is a Senior Technical Writer at Phoenix Technical Publications. Phoenix Tech Pubs has provided complete technical writing and documentation services in the San Francisco Bay Area for over 25 years.