DocAve on the Ground

The U.S. Navy recently added AvePoint’s flagship product, the DocAve Software Platform, to the Application and Database Management System approved (DADMS) software list, authorizing the technology for use within the Department of the Navy.

The DADMS is a registry of the official Navy and Marine Corps IT systems and applications allowed to go onboard a Navy ship. Each application on the DADMS list has been carefully examined and deemed fully compliant with the Navy's application reduction initiative.

“Securing DADMS approval is important in our ongoing commitment to the U.S. Navy and U.S. Marine Corps to help the war fighters manage and administrate large SharePoint deployments – on the garrisons, on ship, or deployed in theater”, said Butch Zachrel, Federal Enterprise Executive at AvePoint. “The DocAve Software Platform is the only solution that addresses multiple SharePoint requirements in these mission-critical environments.”

AvePoint is no stranger in having its software solutions deemed fully compliant with mission-critical federal organizations. AvePoint received a Certificate of Networthiness – issued by the U.S. Army Network Enterprise Technology Command –for the DocAve Software Platform in December 2009. This certification is required for all external software deployed on the U.S. Army’s networks.

AvePoint is also in the process of ensuring the DocAve Software Platform has total authority to operate within the Air Force. Sponsored by Air National Guard 146th Air Lift Wing, the DocAve Software Platform is currently in Phase 3 test and build for its accreditation with the Air Force. Full accreditation is expected before the end of this fiscal year.

 
Expert's Corner

SharePoint Server 2010: Records Management Overview (Part 2 of 8)

Written by: Mack Sigman, Senior SharePoint Solutions Architect, MicroLink

In the first installment of our eight-part series on SharePoint Server 2010 Records Management (RM), we identified the elements necessary in order to craft a scalable, successful RM system. Now that we have discussed the building blocks of RM, we will explore the planning steps necessary to ensure the records management system (RMS) established for your SharePoint Server 2010 environment will achieve your organization’s RM requirements and goals.

The following is a preview of the RM planning process:
 
• Identify specialized RM roles

Include records managers and compliance officers to categorize the records in the organization as well as run the RM process. IT personnel are then necessary to implement the systems that will efficiently support RM. Content mangers must be granted authority to find where information is kept within the organization, and ensure their teams follow established RM practices.

• Analyze organizational content

Before creating a file plan, records managers and content managers must survey document usage in the organization in order to determine which documents and other items can become records.

This survey will include identifying what kind of metadata is being applied to the current content and which metadata should be applied (there might be a very large delta), as well as determining which content types are currently being used. SharePoint Server 2010 introduces new features to help in this aim: enterprise metadata management and content type hub syndication.

In Microsoft Office SharePoint Server (MOSS) 2007, site columns and content types provided a very powerful capability in this area, but could not span across site collections. That proved unacceptable for organizations with several site collections. SharePoint Server 2010 eliminates this limitation, and allows you to create a centralized hub for content types that can be consumed by all the other site collections. One of my favorite new features is the Content Organizer, which provides a “Drop-Off Library” where all content can be routed and – depending on the associated metadata – can automatically be deposited in the correct library location using the metadata. We will do a deep dive on that in the next article.

• Develop a file plan

After you have analyzed your organizational content and determined retention schedules, fill in the rest of the file plan. File plans include – but are not limited to – a description of the kinds of items the enterprise acknowledges to be records, indicate where they are stored, and describe their retention periods. Think of this as though you are a librarian, and the content is the books on the shelves: How are you going to organize it all in a manner so users can find exactly what they need? The process you go through here can be used for how you decide to structure your content in the portal as a whole, not just for the RMS portion.

• Develop retention schedules

For each record type, determine when it is no longer active (being used), how long it should be retained afterward, and how it should ultimately be disposed. This will be similar to the process you go through in determining retention polices for the portal as a whole. SharePoint Server 2010 introduces multi-step retention policies, so you can have the system launch a review workflow – Is the content still relevant? – and then either continue to retain the content in question, delete it, send it to another archive, and so forth.

• Evaluate and improve document management practices

 Make sure that required policies are being applied in document repositories. For example, ensure that content is being appropriately audited so that suitable audits are retained together with records. As I stated earlier, there are a lot of core features in SharePoint Server 2010 that are germane to RM, but are also applicable to the portal as a whole. We will do a deep dive into those other features in future articles, so please stay tuned.

• Plan how content becomes records

If you are using SharePoint Server 2010 for both active document management and RM, you can create custom workflows to move documents to a records archive. If you are using either SharePoint Server 2010 or an external document management system, you can plan and develop interfaces that move content from those systems to the records archive, or that declare a document to be a record but do not move the document. You also create a training plan to teach users how to create and work with records. SharePoint Server 2010 introduces the concept of “in-place records”. Unlike MOSS 2007, in which the content had to be moved to the Records Center to be a record, you can declare a record “in place” and it remains in its current location (where it might be something the team is still actively working on).

• Design the RM solution

Determine whether to create a records archive, to manage records in place, or to use a combination of the two approaches. Based on your file plan, you will either have to design the record archive or determine how to use existing sites to contain records. Then, define content types, libraries, policies, and – when it is required – which metadata will determine where to route individual documents.

• Plan email integration

Determine whether you will manage email records in SharePoint Server 2010, or whether you will manage them within the email application itself. Part of this will be determined by which version of Microsoft Exchange your organization currently has deployed, but please consider that many important decisions are made via email and are consequently important records that should be retained.

• Plan compliance for social content

If your organization uses social media such as blogs, wikis, or My Sites, determine how this content will become records. In SharePoint Server 2010, all these can now be declared as records, so you can capture important content generated through the use of social networking tools.

• Plan compliance reporting and documentation

There is a saying I learned during my 20 years on active duty in the U.S. Navy, “You don’t get what you expect, you get what you inspect.” Auditing and reporting on your RMS will help verify that your organization is performing its required RM practices properly. The RMS documentation should be published to the organization, and these practices must be communicated to the organization so no one can claim ignorance to the policies. This is much easier said than done; anyone who has tried to institute a cultural change in any organization will know what I mean. We will discuss several approaches to tackle this challenge in a later article, as the stakes for not doing so are quite high. There has been an influx of large organizations involved in some form of litigation, and if your organization becomes engaged in records-related litigation, you might have to produce these RM guidelines, implementation plans, and metrics on effectiveness. If your organization fails to document RM plans and processes, leading to constantly changing, ad hoc policies, there could be monumental ramifications.

About Mack Sigman:
Mack Sigman has more than 15 years of experience in the IT arena, including expertise in portal design, information architecture, and knowledge management. Sigman’s expertise also includes application development, systems integration, team building, gap analysis, knowledge management, portal and web development, project management, business requirements analysis, vendor selection, and strategic/tactical planning. Sigman is a Microsoft Certified Systems Engineer specializing in SharePoint and Information Worker collaborative solutions based on the .NET Framework.

---

 

Best Practices

With DocAve Administrator for SharePoint, it is now easy to transfer permissions from Forms Based Authentication (FBA) users to AD Active Directory (AD) accounts with batch operations. These enhancements in DocAve Administrator allow for manipulation of permissions and groups through an import/export with Excel Spreadsheets.

 To transfer permissions using DocAve Administrator, select the scopes you wish to modify in the tree view of your farm, and then perform a security search. To return all users that are authenticating via FBA, you can use a wildcard “*” in the FBA Users field. After executing the search job, retrieve the results in the Job Monitor and choose “Export for Edit” to download the spreadsheet.

After you have downloaded the spreadsheet, you will have a list of URLs, Object Names, Accounts, and Permissions as listed below:

Path	Obj. Name	Path Type	Name	Account Type	Permission	Change
http://intranet	Intranet	Site Collection	FBAMember:user1	User	Full Control;
http://intranet	Intranet	Site Collection	FBAMember:user2	User	Contribute;

To change the members listed above -- delete FBA users while adding appropriate AD users – make the following changes in the spreadsheet as listed below:

Path	Obj. Name	Path Type	Name	Account Type	Permission	Change
http://intranet	Intranet	Site Collection	FBAMember:user1	User	Full Control;	Delete
http://intranet	Intranet	Site Collection	FBAMember:user2	User	Contribute;	Delete
http://intranet	Intranet	Site Collection	ADMember\user1	User	Full Control;	Add
http://intranet	Intranet	Site Collection	ADMember\user2	User	Contribute	Add

After saving your changed spreadsheet, return to DocAve Administrator. Choose your farm, select “Security Center”, and choose “Import Configuration File”. Upon the successful import of the spreadsheet, the permissions changes will be made to all paths/objects listed in the spreadsheet in one operation. That same operation can then be modified to easily manage permissions across multiple site collections, sites, libraries, and lists, improving productivity while reducing security, compliance, and performance risks.