Description

This guide provides the base framework for proper backup and restore of a ProjectDox 8.3 website

Solution

Please see attached document for backup instructions. 

Revised 02-18-2015

Electronic Plan Submission Best-Practices

A Practical Guide for Jurisdictions

Avolve Software Corporation 4835 East Cactus Road, Suite 420 Scottsdale, Arizona  85254 www.avolvesoftware.com

Introduction

With the advent of electronic plan submission and review systems and their implementation by jurisdictions, the question of how to control incoming and outgoing files, and more specifically, what file formats to accept from private and commercial entities becomes an important issue for local government departments to address.

Electronic Plan Review Submission Best-Practices presents a summary of what jurisdictions should consider as they open their online doors to their respective communities and commercial partners.

The premise of electronic plan technology (ePlan) is two-fold, namely that, 1) given a choice, most professional organizations would prefer to submit plans electronically – as long as they can be assured of a secure environment and realize economic benefit, and 2) the jurisdiction is continually engaged to reduce costs, increase operational efficiency and the range and quality of services – while maintaining their regulatory enforcement mandate – by leveraging the advantages of new technology as much as possible.

In that the responsibility to develop an appropriate electronic review process and invite the community to participate in such falls to the jurisdiction, guidelines that delineate expectations and best guarantee consistent results are needed. For the citizen, knowing exactly what to do isn’t obvious, and the required details are not always easily communicated and enforced. Care must be taken to account for the plan submission aspect of ePlan system deployment and process management.

The main topics discussed in Electronic Plan Review Submission Best-Practices are as follows:

• What submission formats best serve the jurisdiction for the review process (actual plan files)

• Preparing the citizen-customer to submit files in the desired format according to set requirements

• File security and the submission process

• Post Submission Issues

Moving from paper blueprints to electronic files for plan review does provide both the citizen and the jurisdiction with several important advantages, but without proper expectations and the ability to convey them to ePlan system users, some benefits can be compromised or even evaporates.

Don’t let that be the case for your jurisdiction.

Avolve Software Corporation Makers of ProjectDox ® Electronic Plan Solutions for Government

1. The Plan Files: Where It All Begins

With respect to electronic plan review, the basic component that concerns everyone is the plans themselves. The majority of digital architectural and engineering plans that wind up being submitted to a jurisdiction are created using a relatively small number of engineering software products, such as Autodesk’s AutoCAD or Bentley’s Microstation. The most common native file formats produced by these programs are DWG and DGN. Native files produced by authoring software can normally be exported or saved in common portable formats such as PDF or DWF.

Drawing files that are generated in the land development and building design process are complex and often contain multiple, discipline-specific layers, imbedded data and reference information to other files created during separate design and drafting sessions by one or more designer/engineers. The native files are saved in vector-based formats that respond to manipulation by the range of design tools in the authoring program as well as third-party software applications. Because of the amount of information contained in the native file format as well as the associated data references, they are often fairly large, and present a couple of key challenges to electronic/automated processes (see Native Files below).

Converted Files vs. Native Files

Converted Files

Converting native engineering files to another format for the purpose of distribution and review is a common industry practice. The conversion operation is performed by the citizen customer prior to submission. There are essentially three options:

1. Bitmap Images – *Not desirable – but workable if necessary*

In some cases drawings are saved or exported as a “flattened”, single-layer representation called a bitmap image (such as Joint Photographic Experts Group [JPEG] or the Tagged Image File Format [TIFF]). TIFF files can also contain multiple pages representing different layer and design views. In some cases, this can increase the file-size for transport (sometimes dramatically), but generally prevents the drawing from unwarranted manipulation. A compression algorithm can be applied to a TIFF file (JPEGs are compressed to some degree by default) in order to reduce the size of the file for transport and/or storage.

However, when architects and/or engineers convert vector-based drawing files to bitmap images to address intellectual property security, or meet minimal jurisdictional submission requirements, important vector properties are removed including:

• Layer Information – Electrical, HVAC, plumbing and other distinct elements are placed on individual drawing layers that can be revealed and hidden, allowing for faster, more accurate viewing. Without layers, reviewers will either require separate drawing files per layer, or worse, have to discern each element on the single bitmap layer – even more difficult. Being able to toggle between layers in a vector file helps all reviewers visualize the overall relationship of each layer to the others at once, even though review tasks may be restricted to a single layer in the drawing.

• Font Information – Allows notes and other text-based data to be indexed and searched. Without this, finding specific information or using metadata and keywords to find it quickly is not possible. This also has an important impact on best-practices for archival and retrieval.

• Scale and Measurement – Accurate measurements will force some recalibration by viewing software if measurement tools are available; if not, precise measurement can be at risk, not to mention optimum efficiency.

The above properties can be leveraged to expedite review and approval, and can support potential future operations. Thus, best-practices for plan submission will seek to avoid this type of conversion if possible, especially in the early stages of the ePlan process.

1. Scanned Blueprint Files – *Avoid, if possible*

Besides a paper blueprint itself, scanned blueprint files (usually TIFF), while sometimes necessary for the jurisdiction to accept and utilize, are perhaps the least desirable format for the ePlan review process, especially if the citizen-customer does the scanning. Exact alignment between multiple layers and views, visual anomalies and distortions, and overall quality control and consistency are significant issues that can compromise the original plans. If file compression is applied during export, visual information can be partially or completely discarded that might prove important for reviewers. It is recommended that, if accepting scanned documents is required for the jurisdiction, the citizen be asked to use professional scanning services prior to submission or that the jurisdiction provide them at the permit counter in order to guarantee quality scans.

1. Portable Vector Files – *Preferred*

Files that are converted to a portable vector format (i.e. DWF and PDF) that removes certain expendable information, but maintains important properties that assist in streamlining the review process, are preferred. Many of the jurisdictions that practice ePlan review today are standardizing on PDF as the format of choice because it is ubiquitous and supports a full complement of spatial vector data, including layers and fonts, as a “print-ready” file. Onscreen, a print-ready file is a replica of the actual paper plans that many reviewers are used to seeing. This makes transitioning to electronic review from paper easier for department staff. It should be noted that while PDF is typically accepted by jurisdictions that perform electronic plan review, conversion anomalies do exist depending on the citizen’s technical skill level and software program used for conversion – not all PDF files behave in the same way.

Native Files – *Best*

Electronic plan submission should support the use of native vector files because of all the information and attributes they contain as well as their inherent visual fidelity. However, architects and engineers are not inclined to send intellectual property-rich drawing files outside their corporate walls except under tightly structured and controlled security procedures. Also, jurisdictions are not inclined to purchase expensive CAD software seats and maintain the expertise required to use such complex tools. The apparent impasse can be solved by the proper implementation of an electronic plan system that offers:

• A secure file transport, storage, access and review process and infrastructure

• Automatic format conversion tools that reduce file size but maintain fidelity and the necessary attributes contained in the native DWG/DGN file format after the file has been received by the jurisdiction. Publishing technology that creates a high fidelity rendition of the original file and conveys all the necessary attributes to the screen for use by review team members, while protecting the original files from modifications guarantees the integrity of the intellectual property while delivering everything needed to optimize and automate the plan check process.

• Publishing support for all common native formats used by architects, engineers and contractors.

• View, markup and communication tools well-suited to the primary task of identifying and recording required changes with respect to code enforcement.

These requirements highlight the issues of file transport (moving drawing files from the author to the jurisdiction and back again) and what happens to the files during and after the initial transfer, as well as the internal review process itself. This will be discussed later in the Security section of this document.

Multiple File and Multiple Page Submission – The “Print-Ready” Master File

While it is true that (both portable and) native file formats provide the highest fidelity and the maximum amount of project information, reviewers can be disadvantaged when having to “assemble” multiple reference files if the citizen fails to consolidate them into the main, or “base” drawing file. Binding up the base file with all the external references and creating a “print-ready” master file takes a few minutes of the author’s time and saves significant time and effort for reviewers. The advantages of a print-ready file for submission will be discussed further in the next section.

1. Preparing the Citizen Customer for Proper Submission

Regarding electronic plan submission best practices, one of the most important tasks facing the Jurisdiction is proactively communicating with citizen customers with the goal of preparing them for file submission according to jurisdiction requirements.

Included with this white paper is a sample of such a preparation document for review. Jurisdictions are encouraged to learn and borrow good ideas from their peers at other communities. Keep in mind that, for the citizen, it is likely that little or no preparation for submission occurs prior to the permit application, which means that there is a window of opportunity to communicate what is expected. However, unless detailed submission requirements are communicated clearly in a timely fashion, the user experience, for citizens and reviewers, will be problematic.

Preparing the citizen customer includes the following activities:

1. Developing an effective and thorough submission process

2. Establishing detailed submission requirements

3. Creating an effective requirements delivery vehicle to the customer

4. Implementing methods to confirm that communication has taken place

5. Setting up some accountability within the process

Developing an Effective Process

It goes without saying that some form of submission process must occur with any ePlan system deployment. The question is how much time and effort will be spent to ensure that the process is well-conceived and accounts for all the contingencies involved. Implementing an ePlan solution is, for most every jurisdiction, uncharted territory and involves some trial and error.

Often jurisdictions will, at first, choose to develop their ePlan solution under a shroud, not wanting to risk too much public or inter-departmental exposure while ironing out the wrinkles and fixing the bugs. However, the most successful programs engage a sample of the internal stakeholders and citizen (usually commercial) customers early-on, first to help promote the advantages of new technology, but also to solicit valuable input in pursuit of a system and processes that actually meet users’ needs. It is recommended that, at appropriate milestones in the project implementation plan, that real-world users become exposed to system features with a view to refining it for broad use in the community. Preparing the customer means understanding how he/she performs his/her job and steering them in the required direction, and not always dictating a set of rules. Jurisdictions have yet to report a refusal to participate on the part of their prominent stakeholders.

Establishing Submission Requirements

The previous section dealt with file formats and their characteristics. Proper submission also includes the consistent labeling of files and sheets, including a complete index of all files being submitted. While every jurisdiction will have differing requirements based on previous practices, it is important to consider the differences between digital media and paper when developing requirements for submission, and also the complete lifecycle of the files submitted. Will

Figure 1: Sample Electronic Plan Submission and Review Workflow

(Courtesy of Osceola County Building and Planning)

 See Attached Image

the files be named one way for review and another way for archiving? Which files will be kept? How many revisions of a given file or sheet? The entire process should be accounted for before issuing requirements for the citizen-customer in order to avoid unnecessary modifications.

A checklist that becomes part of the standard procedure for citizens can include:

1. Submission cover sheet

2. Project cover sheet and file index

3. Drawing file naming conventions – some jurisdictions utilize portions of the permit application number

4. Sheet naming conventions – establish a sheet naming convention that conforms to your operational and lifecycle plan. (see Figure 2a, next page)

5. Border standards – establish designated areas for stamps and title blocks, etc.

6. File-type standards – list acceptable file types for each type of document, drawing, image etc. You can also provide instructions regarding how the customer should convert or publish specified documents.

7. Folder Structure standards – discuss which folders various document and drawing files should be uploaded to when submitting/re-submitting.

8. Markup/Annotation color conventions – establish which colors will relate to specific disciplines (see Figure 2b, next page)

Single File/Single Drawing/Single Sheet (See Multiple File and Multiple Page Submission above)

While there are many potential ways to package up drawings for submission, it is advisable to instruct the citizen customer to provide drawings as single files containing a single sheet, and not as multi-page files. The idea is to prepare the submission in such a way that when a file is opened onscreen a single sheet is displayed – just like rolling out a single blueprint sheet. Had they chosen to submit in paper, citizen customers would prepare their files for the reprographics house in the same fashion, so it is not extraordinary to require this type of packaging. The term “print-ready” mentioned above appropriately describes the status of files ready for ePlan submission.

There are several advantages to this method. Individual drawing files containing multiple pages and multiple layers are unnecessarily complicated to navigate and manage. When corrections and markups are necessary (and they are always necessary) extracting single pages from multi-page files can be time consuming at best, and confusing or the cause of file corruption at worst. A single sheet with a unique filename for markups and annotations is much more direct and easy for both reviewers and citizens to identify, modify and then re-submit. If a single sheet file becomes corrupt, remaining sheet files can still be used; a corrupt multi-page file is of no use. Collections of sheets can be divided up into separate folders for department-specific reviews when required. Maintaining a single-file to single-drawing sheet relationship also makes it possible to leverage side-by-side and overlay-compare features easily and accurately.

Single sheets can contain multiple layers, and if converted to a portable format such as PDF, combined into a single file at the conclusion of the project for archiving if that is deemed necessary. Layers on single sheet files can be turned on and off in order to isolate views and add comments and markups normally.

Delivering Requirements to Citizen Customers

Making sure that a customer receives and reviews your requirements, as well as being able to comply with them with reasonable effort, is also essential. It is a good idea to map various delivery and verification steps into the overall submission process. Jurisdictions can provide this in the following ways:

1. Develop a electronic plan submission guide that incorporates a requirements checklist and submission steps in a single, easy-to-use document that is accessible in print and online. (see the sample provided – courtesy of Clark County, Nevada Planning and Development)

2. Use the existing permit application process as an opportunity to educate the citizen customer. If online permit application is available, use the web-based process (web pages) to promote ePlan submission. Use the permit counter/manual application process in the same way ­­- people waiting in line can use their time to become aware of and learn about electronic plan submission. Make sure that you provide multiple paths to the information. One jurisdiction actually allows citizens to “test drive” electronic plan submission so they can see how easy it is.

3. In online permit application scenarios and email communication, optimize the use email notification combined with web technology to educate and even verify required activity. Examples include auto-generated emails with embedded instructions and/or attachments (such as the submission guide), e-form web pages that record activity and update status, and time or event-triggered notifications. Workflow technology can be utilized to automate communication, such as sending reminders to keep the process moving. Polling plan directory folders per a schedule can provide the jurisdiction with information about citizen activity, such as when submissions have occurred and what folders have been populated.

Figure 2a: Drawing Sheet Naming Table

Figure 2b: Markup/Changemark Color Legend

A word of caution: Leveraging technology opens up a number of ways to help automate tasks, but applying technology to a flawed process will not fix it. Be sure to assess the fundamental aspects of what you are trying to accomplish with respect to your citizen-customer and then use technology to enhance them.

Accountability Support

When all is said and done, the jurisdiction will need to apply human activity to check that the requirements for submission have been met. Current ePlan technology still requires oversight and assistance from the review team. However, if citizen-customers have the opportunity to be exposed to the proposed process prior to implementation and provide feedback, it is very possible for the jurisdiction to deploy a well-conceived submission methodology that communicates requirements effectively and minimizes the need for excessive monitoring.

1. Security and the Submission Process

Another important issue that jurisdictions must address when implementing electronic plan submission best-practices is providing a secure and managed way to upload files to a central file server. Regarding security, uploading files via a network is not really the problem; the issues lie with the proper controls needed to send/receive files from multiple and disparate sources and then automatically join them to a permit processing and accounting system that is run separately of the plan review process.

However, using the Web presents its own set of challenges, which are as follows:

Network Security – Any publicly-accessible network system being used to transport plan files must be reasonably secure to the extent that network pipes and file servers cannot be infiltrated or disrupted by unauthorized and hostile personnel. Best-practices for implementing such a network/server system are established and continue to evolve, so they are not the subject of this plan submission discussion.

Trusted Sources – Network and file security raises the subject of trusted sources. With respect to network protocols, the standard HTTPS Web protocol utilizing SSL is the only practical choice for a publicly accessible network and accompanying file transfers, because it is ubiquitous and incorporates a means of verifying the identities of the nodes uploading files to the jurisdiction as well as providing trust that the jurisdiction is the actual destination of the files being sent. Some jurisdictions are planning to require pre-qualification, training and managed accounts for commercial firms that will be uploading multiple files often. Trusted source issues also touch on the practice of “wet-sealing” plans, proper sign-offs and current state regulations that sometimes require affixed seals prior to submission.

Wet-Seals and Digital Signatures –A concern that dovetails with the topic of trusted sources is the practice of wet-sealing architectural and engineering plans. Electronic plan submission assumes that no paper documents have been required of or generated by the citizen-customer during the submission process, or by the jurisdiction through the end of the review. However, many states and standards bodies require “wet-seals” or other types of affixed seals to paper documents submitted to the jurisdiction prior­ to plan review and approval. Regrettably, with respect to an all-digital process, there is no prospect of meeting every state’s requirements in one fell swoop even if an industry-standard digital signature methodology existed – and it does not.

Jurisdictions are trying different ways to meet wet-seal requirements half-way in an effort to accommodate the law. Some require a single, full set of wet-sealed plans up front – once. Others are asking that the citizen-customer provide a wet-sealed index list of all plan sheets which they can verify after the drawing sheet files are uploaded. Some have considered asking the architect/engineer to wet-seal the final set of approved plans that are printed and ship a set back to the jurisdiction.

The means to perform a legitimate digital signature is well established; it is the application of the technology in the context of the submission/re-submission process that poses the challenge, especially as it concerns widespread required use, technology costs, ease-of-use, and liability as the law defines it.

There is one common thought that prevails among all the jurisdictions deciding for electronic submission and review: Despite current laws, the wet-sealing issue is not going to stop them from implementing electronic plan technology – in at least some fashion – because the advantages of doing so are too numerous. There are efforts underway to tackle the question of a fully digital, certifiable signature/seal process that does away with the need for the traditional wet-seal, but if jurisdictions wait for state legislatures to act, they will fall too far behind technologically.

A best-practice for this aspect of electronic plan submission currently does not exist. Jurisdictions are encouraged to 1) design a system and process that is legally viable and sensible, and 2) contact their electronic plan review peers and continue exploring what is being done to deal with this particular issue.

Submission Lock-Down – Jurisdictions need to control access to project folders based on the specific phase of the review process. A key security practice is to provide a means to determine when all required files have been received and then shut off access to the file folders from any outside person or entity. Failure to do this allows for the potential modification of critical files in mid-review. Re-submission should occur only according to the designated completion of specific tasks by each department.

Electronic Approval/Rejection Stamps – For the foreseeable future, moving to paper is still the practical way for a construction entity to utilize the plans on the job site, and so jurisdictions employing electronic plan submission and review will need to decide how best to accommodate this step. Electronic plan technology allows the Plan Review Supervisor to “stamp” the plans with a tamper-proof electronic image that is “burned into” the approved plan set and is checked by the Field Inspector when he reviews the permit and the construction drawings on the jobsite.

Bandwidth – Sufficient network bandwidth must be in place to expedite the transfer of multiple and potentially large files without interruption, creating a consistent and pleasant user-experience. File compression is often used to reduce the overall size of the file transfer and minimize bandwidth use.

NOTE: ProjectDox®, the electronic plan solution from Avolve Software Corporation, creates screen renditions of all submitted files, no matter the native or converted format. All “original” files submitted are stored and cannot be accessed except by specific permission. Markups and annotations are applied to virtual layers that are managed by the ProjectDox application. It is not possible to modify any design element of a drawing sheet file with the tools given to ProjectDox users – such is reserved solely for the author of the native file. Combined with a proper workflow process and applied user permissions, it is virtually impossible to effect any change to a drawing file when using ProjectDox. This is an important security feature for system users concerned with the file integrity through an electronic submission and review process via LAN/WAN technology.

1. Post-Submission

Using electronic plan technology workflow tools and other features, jurisdictions can effectively address post-submission concerns surrounding re-submission, approval and printing, inspection, as-built drawings and archiving.

A few comments regarding some of these issues:

• Re-submission should be done as “print ready” files – discussed above

• Use file compare features extensively to review re-submitted plans in order to catch modifications that were not present in the initial submission and therefore not subject to review.

• Approved plan sets should be stamped electronically and “burned in.” Final, approved plans should be easily identifiable and stored in a specific folder. PDF is a preferred format for download by the citizen-customer.

• If required, approved plan sets can be printed and wet-sealed by the Architect/Engineer as a binding legal document in possession by the jurisdiction.

• Inspectors should be made aware of the ePlan process and verify all applied jurisdictional certifications on the job-site plan set. They should be granted access to final, approved plan sets online to make notations and corrections per the jurisdiction’s “As-Built” process.

• Discrepancies between the job site and approved plans are to be noted and corrections made through additional, post-inspection notification and resubmission by the citizen-customer. Certificates of Occupancy can be dependent upon receipt of accurate As Built plans in the system.

• Archiving project files should be done in such as way as to facilitate easy, rapid retrieval and distribution to authorized agencies and personnel when structures and/or land areas are deemed critical to community safety and security. Many different criteria can be applied against a particular project to determine its specific and overall importance. It is recommended that post-project accessibility be included in any ePlan deployment planning exercise.

To get more information or speak to an ePlan expert, contact:

Avolve Software Corporation

4835 East Cactus Road, Suite 420

Scottsdale, AZ 85282

602.714.9774

www.avolvesoftware.com

info@avolvesoftware.com

Revised 02-18-2015

Number: SB20100428-003

Date: 28 April 2010

Subject: To Multi-page, or Not to Multi-page? That is the Question!

ProjectDox supports uploading multi-page documents. But are they recommended?

Applicants and reviewers alike search for ways to simplify and speed up their respective tasks in the submission and review process. One apparent solution is to use multi-page files, and ProjectDox supports uploading multi-page documents. But when are they recommended? This bulletin explores the advantages and pitfalls of multi-page files.

Text based files

Multi-page files can be a useful and convenient format for text-based files: documents, specs, reports, and other permit review files, created as Word or PDF files.

Drawing files

Using multi-page files for plan review drawings is not recommended. A multi-page drawing file may be defined as a single file that when opened, contacts within itself multiple drawing pages. An example is a PDF file that when opened would contact multiple drawings as pages within the file.

While this file format is convenient for an architect to pass on to an owner for review, the convenience stops there.

Of 45-plus jurisdictions using ProjectDox today for electronic plan review, not one currently allows the submission of multi-page drawing files (regardless of format or the generating application). Listed below are some of the drawbacks that accompany the use of multi-page drawing files:

1. Producing - The applicant would not deliver files in this format to a reprographics house for printing. For an applicant to submit files in this format to the jurisdiction for electronic plan review, an extra step is required, compiling the drawings set and publishing it into one multi-page file.
2. Uploading - The multi-page drawing file will be larger with longer upload time.
3. Viewing - Once the multi-page drawing file is uploaded into ProjectDox, it will be transferred in total (full size) every time it is opened for view or review. If the applicant had uploaded multiple drawing files instead, viewing would only require opening the specific single page file — with much less overhead.
4. Overlay Compare - This hallmark feature in ProjectDox works with two different multi-page drawing files like version 1 to version 2, but not two different pages within a single multi-page drawing file. If a structural plans examiner wants to overlay the mechanical drawing on top of the structural plan they are reviewing, it can't be done within the multi-page drawing file. The examiner has to print physical copies of the plans for review.
5. Markups and Resubmission - After markups have been made on a specific file sheet, the link to that multi-page drawing file is attached to the resubmit notice for the applicant to review and correct. The applicant has to open the full multi-page drawings file again — transferring the full file over the internet for viewing within ProjectDox. This process can drain network resources, and waste time for both plans examiners and applicants.
6. Uploading New Versions - The previous issues are perpetuated when the applicant makes required changes to address the markups on several pages of a drawing set, and then has to compile all the drawings again, publish and upload another multi-page drawing — all this repeated for every review cycle.
7. Checking for Changes - Once a revised multi-page drawing file is uploaded, ProjectDox will version the file and send a task notification to all plans examiners that a new version has been uploaded. Each plans examiner must open both the old and the new versions in overlay compare, find the markup(s) that were created, and then navigate between versions to see what was changed. If the applicant had instead uploaded single-page files only for the drawing sheets with changes, then the plans examiners could immediately see in the ProjectDox user interface which files had been versioned.
8. Batch Stamping - ProjectDox can batch stamp all pages of a multi-page drawing file, but it must be the same stamp in the same physical location on all pages. By using a multi-page drawing file, jurisdictions lose the flexibility to vary content and position of the stamps from page to page.
9. Printing - After the multi-page drawing file is approved and stamped, ProjectDox notifies the applicant that they can download their approved drawings. Now the applicant must reverse the initial process: the multi-page file has to be separated into single drawing sheets for distribution to contractors and subs, as well as for printing.

In summary - At first glance, a multi-page file may seem like a good way to keep everything in one place, and this may be true for text-based files. For drawings, however, multi-page files impose many disadvantages on both applicant and jurisdiction. Therefore, we strongly recommend permitting only single-page files for drawing submissions.

Revised 02-18-2015

Description

Brava scalability touches many parts of the system, including the integration in which Brava runs.   This section covers scalability and fault tolerance of the Brava system itself. Integration scalability is covered in a separate section.

Solution

The attached white paper that was released by the makers of ProjectDox Publishing Engine, Informative Graphics, provides a very good understanding of the architecture used for the publishing paradigm in ProjectDox.

Revised 02-18-2015

ProjectDox Server Administration, Backing Up & Monitoring Tips

The attached document has additional information regarding the administration of the ProjectDox servers including Backing Up and Monitoring the servers for issues.

When modifying the SSRS reports, make sure, before checking them in, that they export correctly in PDF. Some of the reports are not easily printed on 8.5x11 sheet of paper, make sure they all export into one page width in PDF. This means, no extra blank page and no grids that get cut off and put on extra pages.

Here how to prevent that:

1. Click on Report > Report Properties > Layout tab (Page Setup tab in SSDT-BI)
2. Make a note of the values for Page width, Left margin, Right margin
3. Close and go back to the design surface
4. In the Properties window, select Body
5. Click the + symbol to expand the Size node
6. Make a note of the value for Width

To render in PDF correctly Body Width + Left margin + Right margin must be less than or equal to Page width. When you see blank pages being rendered it is almost always because the body width plus margins is greater than the page width.

Remember: (Body Width + Left margin + Right margin) <= (Page width)

To get the body width, click on the white part of the body of the report and in the properties screen on the right you’ll see the measurements. To get the report width, click on anywhere outside, not on the report, and in the properties screen on the right you’ll see the measurements.

Contributed by: Chris Wright

Contributed on: 2/27/17                    

Description

Customers with anti-virus installed on the ProjectDox Servers must enable the following exclusion rules in any scanning utilities installed to prevent issues with the function of the software.  Avolve recommends that only the PdoxTemp folder be scanned in real-time.  All other ProjectDox application folders and supporting folders, including all sub-folders, should be excluded from anti-virus applications real-time scanning.  A nightly scan of the directories is acceptable.  It is not recommended to have anti-virus installed on the Job Processors.  Avolve cannot guarantee the operation of the Job Processors with anti-virus installed on the servers and, in the event issues occur with publishing, the first recommendation will be to remove the anti-virus application from the Job Processors and perform a full reboot.  Perform testing after the Job Processor has been rebooted to see if the issue is resolved.  

Solution

Avolve recommends setting up exclusion rules for the folders specified below on the ProjectDox servers indicated.  Assuming the Operating System is installed on the C:\ drive and the ProjectDox, related services and Brava applications are installed on the E:\ drive, you would want to exclude the following folders, including any sub-folders, on the ProjectDox servers.  A list of common Share Folder Names used by ProjectDox is provided below.

• UserFilesSource or UFS - Stores original files uploaded by users
• UserFilesPublish or UFP - Stores published ActiveX version of files uploaded by users
• DLCache - Stores published HTML version of files uploaded by users
• Queue - Stores Job Tickets created for publishing requests for the Job Processors
• PdoxLogs or Logs - Stores Archive PDFs if using ProjectDox Archive Feature
• PdoxExport or Export - Stores Exported Projects until retrieved by EDMS solution
• WFlowDLLCache - Stores ProjectFlow workflow instance DLLs for active workflows

• PdoxTemp - All uploaded files are stored in this folder first before being moved to the UserFilesSource folder.  This folder should not be excluded as it is the single point of entry for any new files uploaded to ProjectDox and should be scanned in real-time.

NOTE:  Some anti-virus applications may need an additional exclusion rule enabled for .rtf file types.  If you experience trouble with missing Markups or Changemarks within the workflow, then please try adding the exclusion rule for file types of .rtf and see if that resolves your issue.  Markups and Changemarks are saved to the PdoxTemp folder temporarily and some anti-virus applications will false alert and remove the .rtf file causing saved Markups and Changemarks to not show up in the workflow.

Job Processors

     C:\Windows\system32\spool\PRINTERS\  

     C:\Windows\Temp\  **  (see additional info below)

     C:\Users\NetItSvc\AppData\Local\Informative Graphics Corp\

     C:\Users\NetItSvc\AppData\Local\Temp\

     C:\Users\NetItSvc\AppData\Roaming\Informative Graphics Corp\

     C:\ProgramData\IGC\  (Brava 16.2 and 16.4)

     C:\ProgramData\OpenText\  (Brava 16.6 and up)

     E:\Program Files (x86)\IGC\   

     E:\Program Files (x86)\Avolve\    

     E:\Program Files\IGC\   

     E:\JPTemp\  **  (see additional info below)

     E:\ProjectDoxSupportFiles\  or  E:\PDSF  * (see note below)


Web Server

     w3wp.exe Process

     E:\ProjectDox\     (Superion customers may see E:\EPR instead of E:\ProjectDox)

     E:\ProjectDox.Web.API

     E:\ProjectDox.Web.UI

     E:\Program Files (x86)\Avolve\   

     E:\ProjectDoxSupportFiles\  or  E:\PDSF  * (see note below)


Application Server

     E:\Program Files (x86)\Avolve\

     E:\ProjectDoxSupportFiles\  or  E:\PDSF  * (see note below)



NOTE *

ProjectDox file share folders may exist on any ProjectDox server, Network Storage Device or stand-alone File Server. 
The PdoxTemp folder is the single entry point of new files to the server and therefore it is recommended to scan this folder only in real-time.  A nightly scan can be performed of the folders if desired.
Exclude all share folders with the exception of PdoxTemp from real-time scanning. 

ADDITIONAL INFO **

     If you are unable to exclude C:\Windows\Temp on the Job Processors, you can update the system output path of the IGC Writer Print driver and use a different directory for example E:\JPTemp.

To do this:

1. Create a folder on the E:\ drive named JPTemp
2. Grant Full Control under the Security Options for the folder, to the PD_USR and NetISvc accounts
3. In the Control Panel Printers and Faxes panel, right-click on the CSF Writer printer and select Properties
4. Select the Advanced tab
5. Click the Printing Defaults... button
6. Select the Filename Generation tab
7. Change the Output Directory path to the following:  E:\JPTemp
8. Click OK to save your settings.

Then add an exclusion rule for the E:\JPTemp folder on the Job Processors in place of the C:\Windows\Temp folder

SQL Server

Antivirus exclusion on SQL files:

When you configure antivirus software settings, make sure that you exclude the following files or directories on SQL Server machine from virus scanning. Doing this improves the performance of the files and helps make sure that the files are not locked when the SQL Server service must use them. However, if these files become infected, your antivirus software cannot detect the infection.