implementing a taxonomy on a file server

implementing a taxonomy on a file server
Ask just about anyone who stores and retrieves documents on a shared file server if they are happy
with the current structure of folders that they are using and they will reply, “NO!”
Often the state of file servers is dreadful. Personalized taxonomies abound. Duplication is rampant.
Naming conventions are often ignored. Managers and staff alike destroy documents without
reference to a corporate retention schedule. Organizations are at risk when litigation arises and ediscovery becomes a very costly exercise. Corporate memory is being lost.
Then what reasons are put forward by records managers for avoiding digital document
It would take too long and we have limited resources
It’s too technical and IT won’t provide any support
It’s too difficult to calculate benefits or Return on Investment (ROI)
Users dislike change
I am waiting for the organization to purchase an enterprise content management solution
Seriously, these are all myths. And simply put, few records managers have tried to apply basic
records management principles and concepts to improve access to and management of
electronic documents on the file server.
This article will explore the myths that have arisen and set out a simple methodology that any
records manager can follow to restore order and structure to an organization’s servers.
An assumption is made that the organization has a well-designed taxonomy (lots of user
input) and a well-researched records retention schedule that includes justification for
retention periods. If the taxonomy has not been built without considerable input from
users, file server restructuring can easily fail!
Building a File Server Structure
Page 1
Converting hard copy to new taxonomic structures certainly takes a long time, but on a server it is a
very different story. Take for example a small business unit of perhaps 20 – 30 people. Planning
and preparation for the change-over can take 2 or 3 days for a team of two RM (Records
Management) staff, but the actual moving and copying of documents to a new system for
each business unit can be completed in a few hours.
It is important to remember that conversion sessions can be intense and any project team will need
time between business units to recuperate. Additionally, once an area has switched structures, there
still needs to be education and support provided to the business unit as well as monitoring the new
system to ensure it remains effective.
File servers have been around since the mid 1990’s. Most records managers have a reasonable
understanding of data shares, file shares, mapping network drives and basic configurations of file
servers and webservers.
In the past, IT (Information Technology) staff have been unwilling or unable to support RM
initiatives, but as Information Governance brings these areas together, IT infrastructure staff often
look to records managers for help. There is a tremendous amount of work in maintaining a
network, adding applications and supporting the needs of the organization. As result, IT looks to
records management for specific support in managing disposition, establishing naming conventions,
and even in some cases managing security permissions. As well restoring lost or damaged files is
often an integral part of records management responsibilities. However, support is usually confined
initially to assist in establishing some level of organization in folder structures.
But the catalysts that make it possible are simple utilities, and they make this an easy exercise.
Building a File Server Structure
Page 2
There are so many benefits to file server re-structuring it is difficult to believe that tracking KPIs
(Key Performance indicators) or ROI would prove to be a stumbling block.
Basic benefits would be:
o Reduction in File Server space allocation
 Initially 10 % and once a schedule is implemented a further 20 – 30 %
o Reduced back up times
o Elimination of long path names (mitigating risk in the event of a server crash)
o Reduced frustration with server structures
o Reduced training and orientation as staff move throughout the organization
o Reduction in re-creation of documents due to loss, unavailability, or version
problems. An 30 person business unit can see more than 1500 hours a year in
productivity improvement. Although cost avoidance, these benefits are in the tens
of thousands of dollars each year for each business unit.
o Risk mitigation in the event of e-discovery
o Reduced search times
o Reduced filing times
Some of these would require manual calculation but a simple before and after survey should provide
information that will identify benefits and can be moved to a spreadsheet to reduce the impact on
records staff time.
By calculating KPIs and ROI it should increase support for the project and ensure its steady
continuation within any resource constraints of both IT and Records Services.
Of course users dislike change. Resistance to change is a given in almost every organization.
But in this instance, since the taxonomy is basically user designed, the users will be driving the
change. With a predominantly user designed structure, there are always people eager to clean up
their own part of the server.
Moreover, many users have a sub-folder structure that is easily incorporated within the taxonomy
structure. The problem with most servers is that the top level structure is not clearly defined and
aligned with business functions. Once this is done users can see clearly where their piec of the
puzzle fits. In other words the change is NOT that drastic.
Building a File Server Structure
Page 3
Taxonomy development and server restructuring using the taxonomy are foundation projects for
any EDRMS solution. Our experience has shown that significant productivity improvements result
simply from putting a well-functioning taxonomy on a server. Initial savings are 10 % in space just
from elimination of duplication. Eventually when the retention schedule is applied, a further 20 %
in space saving occurs. This reduces search times and minimizes the time needed for server
backups. Also since documents are more readily retrievable, there is a reduction in re-creation of
documents thought to be lost or missing. In an average business unit of 20 – 30 people, the savings
are more than 1000 hours.
By waiting for an EDRMS solution, this can cost the organization significant time in preparing and
implementing the EDRMS product(s). If the server is already restructured migration projects will
be much more rapid and the organization can move to advanced projects such as taking advantage
of workflow capabilities.
The following describes the concepts that must be understood and the basic work that needs to be
done before a server is restructured.
Then finally this article will provide a checklist of specific steps in the restructuring process.
Planning and Managing Expectations
File server restructuring requires a lot of planning and foundational activities. A team of 3 is
usually best. For every one hour spent with a business unit almost 6 or 7 hours of preparation is
needed. If each team member completes a particular role, the team can be ready sooner to assist
the business area. This is especially important as expectations change rapidly after the project
begins. When business areas start to understand what is happening and how much easier it is to
work on the server with a new taxonomy, there will be a flurry of requests for help.
Project Charter
Many guidelines or caveats have been written about taxonomy implementations and all begin with
gaining the support of management. Experience has shown that developing a formal project
charter signed by each business area manager, is a good way to achieve this support.
It is best to review the activities of the project with the manager and provide them with as much
background as possible. The following is a sample charter.
Building a File Server Structure
Page 4
Taxonomy – Server Migration – Project Plan
Project Title
Business Area Name - Taxonomy Implementation Project
Project Lead
Records Management Administrator
Statement of
The Taxonomy Team will work with the Branch/Section staff to review files on private
drives, business unit drives; and the main server drive to identify business records
suitable for migration; obsolete business records suitable for destruction; and nonbusiness files suitable for removal from the system.
Time Frame :
Estimated 1 week
Business Need
Records administrator
Business unit lead – manager or delegate
Business unit team
Business unit administrative contact
IT - system administrator
If the project is completed, the business unit will take the first step towards
substantially reducing the number of obsolete business records and non-business files
in the business unit and shared storage areas. The expected impact is a 25 percent
reduction in disk space and support requirements for these areas, and an appreciable
increase in record-related productivity (e.g. finding, filing, and sharing business
If the project is not completed, the business unit will continue to expend resources on
non-business files and experience issues around record-related productivity.
The project strategy is to leverage staff knowledge to effectively clean up all storage
areas as efficiently as possible. This may involve sorting folders and files to “big
buckets” for related action (e.g. obsolete records in private storage areas are moved
to the shared drive – to an archive folder; non-business files are moved to personal
drive folders, personal memory sticks, etc.)
Project Team
The project team is guided by the corporate records participants, but the business
effort is led by the business unit lead with support from the other business unit
This is a significant and taxing project and should be scheduled when the business
unit can commit to the training and activity schedule. The change management
component is critical to ensuring that staff sees the value in the project activities.
Continuous Improvement of the Taxonomy
Do not assume that all taxonomy design work is complete. Another 10 % of design work,
modifications and adjustments usually occurs. Although in taxonomy design almost all business
functions and activities are defined, as the team works through a particular business areas folders
and documents, information begins to suddenly appear. Documents that were once on a personal
drive and hidden from the taxonomy design team are brought forward to be included. Other drives
that were in use but were not shown to the design team, may contain several new records series.
Building a File Server Structure
Page 5
Path Basics
Essentially paths follow a Windows UNC or universal naming convention. The first two levels are
set by a system administrator. File shares are commonly assigned to organizational units or work
groups. Often if the server is large more than one file share is assigned. Below file share names,
directory names are usually assigned by the organizational unit.
i.e..\\”server name”\”file share name” \”directory name”\”sub-directory name”
or \\” server name”\”file share name” \”root folder name”\”sub-folder name”
e.g. \\ALPHA1\FinanceUnit\Finance\
When mapping to a network drive e.g. X, normally business areas are shown how to map to the root
folder. In such a case, an individual in the Finance Department would only see
Path Issues
The main issues with paths are their structure and their length.
administrator on the web site Server Fault is telling.
A comment by a network
“If there's one truth I've found in imposing organization on others it is this: They were born slobs and
will die that way before I change them. In response to this I have departmental folders on a share.
Under that they create whatever they want.” Chris S 2014
Many systems administrators just throw up their hands when faced with the need for an organized
folder structure. But there are a increasing number of administrators that turn to their records
managers for help.
Path length is a fairly critical concern. The normal maximum path is 260 characters including the
null character at the end of the string. When users are responsible for their directory and
document naming, paths can become extremely long, with duplicate information and complicated
subfolders. If photos are downloaded from smartphones, names can become enormous. As a
result, the path being used may be as much as 280 or even 300 characters long.
Files can still be referenced, but such structures are counter-productive as well as a RISK to the
organization. When such files are backed up, the document names become truncated and the name
changed to include a tilde ~ and a numeric. If there is a complete system crash and prior versions
cannot be located, there would be considerable time and effort needed to open and accurately
rename any document whose name was truncated on the server back up.
To solve this issue, an easy utility to use would be something like TLPD - Too Long Paths Detector.
By entering the drive name and specifying a length e.g. 240 characters, the utility software will
provide a complete list of all paths that exceed this maximum length. Then it is a simple matter to
work with the business area to use a better path structure or appropriate abbreviations for folder
or document names.
Building a File Server Structure
Page 6
Pre – Classification of Folder Structure
Often an existing folder structure can be mapped against the new taxonomy. This would mean that
during conversion sessions, the Records Team can more rapidly make suggestions or quickly
identify and group folders to be moved to the new taxonomy. But it is important to allow the
business area to make their own decisions about folder structures, albeit with considerable support
from the records team. If carefully done as “suggestions” rather than dictating where folders
should go, it should speed the actual conversion process.
To easily map the new structure use a freeware utility like LS File List Generator. It will allow you
to output a set of folders quickly from any drive to a .csv format that can be copied to an excel
spreadsheet to provide room for assignment of the new classification folder.
Building a File Server Structure
Page 7
Migration Tools
When working in a server, it will be necessary to copy or move files and folders rapidly but in such
a way that it is transparent to the business area what is happening. A useful free utility is Free
It allows for display of the old system (to be converted to the new taxonomy) on the one side
usually the left pane and the new system in the right hand pane. It allows you to see sizes of
documents or folders as well as dates. Copy or move functions are simple and it even has a multirenaming function that can expedite migrations.
Structural Tools Needed - Z_Archive and a Filing Basket
Filing Basket
A useful folder to create in the new taxonomy is a Filing Basket. This can easily be brought to the
top of the tree by using an “underscore” i.e. “X:\_Filing Basket. This is useful during implementation
as often the team may encounter complicated structures that may not be easily moved or classified
to the new taxonomy in the time allotted for the conversion (usually one or 2 hours for most
business areas). The complex folder or folders can be simply copied to the filing basket for eventual
Once a system is established the filing basket becomes an excellent place to put any document that
may be difficult to classify or when staff are dashing to a meeting and don’t have time to locate the
exact folder in which the document belongs. It even can be useful if the organization designates
ONE individual to filing documents for consistency or control.
Building a File Server Structure
Page 8
A Z_Archive folder is a key element in allowing for effective disposition of documents and folders.
This folder is created and subfolders are identical to that of the new system. See below
Sub-folder examples
It can be pre-populated or staff can simply copy entire folders to the Z_Archive.
This serves the same purpose as inactive or semi-active file rooms, where outdated material could
be stored in boxes. It removes folders and documents that are not needed for day to day work and
reduces the number of folders that need to be scrolled through or searched when looking for a
particular active document.
Every year or two years, a records person can review the documents and folders in the Z_Archive
folder and match them against a records retention schedule. If records have met their destruction
date, they can be readily moved to a further folder X:\Z_ArchiveDestroy. The utility List Generator
can easily generate a list of folders and documents due for destruction and they can then be
reviewed by management who can sign off on their destruction. This list should also be retained as
evidence of destruction.
Building a File Server Structure
Page 9
Managing Permissions
A critical element in implementation and the copying of documents to a new structure is
understanding the assignment of permissions. External permissions will of course be a concern as
will any folders containing highly classified documents.
Managing Permissions - Assignment of Groups
Who is allowed to work in which folders?
This is managed through the assignment of groups and paying special attention to folders that
contain highly confidential information. There may be several groups in a business unit depending
on the need for access. But usually there are two main groups. In the example below, Gr_Finance
individuals have read, write and execute permissions for documents. Gr_Finance_ReadOnly may
only look at the documents; they may not edit or delete documents.
Often “Role” based groups may be identified, usually management staff or special project teams.
This allows for a very select group of people to be the only ones who have access to a specific folder.
Gr_Finance_ReadOnly or RO
Snow White
Managing Permissions – Assignment of Groups to Directories
X:\Finance\Management Issues
Assigned Permission Groups
In the above table, it can be seen that the Finance Group has excluded the read-only group from
audit files and the only Group allowed to see the management issues folder is the
Although IT network managers or support staff are normally charged with ensuring that these
permissions are assigned, it should be the responsibility of the business area to manage such lists of
groups and be aware of what groups are assigned to which folders. As staff changes, the business
area can notify the IT network people. In the long run, it is anticipated that business areas will keep
Building a File Server Structure
Page 10
their permission lists up to date at least annually and send requests for permission changes to IT on
a regular basis.
New Technology File System NTFS and Active Directory Service ADS are the most common ly used
systems for managing server permissions. Both allow for inherited permissions; meaning that sub
folders can inherit the permissions of the parent folder. It is important therefore to be careful
when adding in sub-folders with greater security needs than the parent folders.
A final note on permissions is that once these have been updated and correctly assigned on a restructured server, many ECM (Enterprise Content Management) systems can import
libraries/directories and keep their permissions intact. This can expedite considerably the
migration of documents and folders to ECMs.
To execute a business area implementation, plan for a half-day for each business unit.
It is extremely critical that the following steps should be followed IN ORDER to ensure that
document integrity is upheld; security is maintained, and that staff develop a comfortable rapport
with the new system and its naming conventions.
Step 1 Pre Conversion Activity
1. Draft the project charter and obtain signature of business area manager. This will require a
visit with the manager and a discussion of what is going to be accomplished and an outline
of this checklist. It is important that the manager understand and commit to the process;
this should not be delegated to a subordinate manager or assistant. Encourage the manager
to also attend the orientation session provided to staff just before implementation begins.
Ensure that the manager appoints some-one as the business area administrative contact.
This person should attend all sessions and be the main point of contact for their area.
2. Ask the Business Area Administrative Contact to identify all Business Area drive names.
This may require help from IT as some drives may have been abandoned over time. Drives
shared with other business areas, very often contain duplicate information from the
business area drive and are simply used temporarily to allow collaboration or transfer of
documents. Often these can be considered transitory.
3. Then request full access to these Business Drives for the Team.
(create a
Gr_Drive_Cleanup). This may mean that the Business Area manager formally requests
Gr_Drive_Cleanup group has execute permissions to ALL Folders on their drive.
4. Send the signed Project Charter, any presentations or tools to be used to Business Area
Manager and the administrative contact.
Building a File Server Structure
Page 11
5. Ensure all staff will be made aware that all business related documents MUST be in the
shared drive and only reference or personal information is maintained in a Personal Drive
or My Documents
6. If KPIs are being tracked make sure that a pre-implementation survey to capture this
information is conducted by as many staff as possible in the business area.
Step 2 Paths, Volumes and Security Prior to Implementation
1. Advise IT of drives to list. Ensure they identify security permission groups (and their
members) and any security controlled folders.
2. Ensure that these are printed and reviewed with the business unit administrative contact.
Staff who should no longer have access should be deleted from permission lists. Verify
current permissions and identify any new security permission groups for new folder
structure with business area administrative contact. Use a spreadsheet or word table.
3. The project team will work with Business Area Admin to determine new groups for
restricted folders and request application of such restrictions once NEWSYS folders are in
4. Flag any high security folders or external access requirements (individuals outside of the
5. Get IT to run TLPD (too long path detector) for each drive and provide a report of any paths
in excess of 230 characters. This may be done simply by the team if using the utility is
acceptable to IT.
6. Work with Business Area Administrative Contact to correct Path name to less than 255
7. Check size of business area drive. i.e. Total Gigabytes of Files and Folders and enter top level
folders and their volume into a spreadsheet. Information can be obtained using Free
Commander utility.
8. Advise IT of total volumes to be copied. Arrange for appropriate space (enough to copy
current documents and provide 5 % growth). Note that copying the structure will allow
hyperlinks, web links and wiki links to remain intact until they can be carefully updated.
Not all links will break if sub-folder structures remain intact.
9. If space is an issue, discuss with IT. Sometimes several business areas will be assigned the
same data share. If volumes are a concern, this structure may need to be adjusted. e.g. if it
looks as though the datashare would be compromised by copying of hundreds of Gigabytes
of folders.
Building a File Server Structure
Page 12
NOTE: If folders are too large to copy,
Flag them so they are not copied (30 GB +). They can be moved during implementation.
Ensure that the NAMES of these large folders are copied to a an empty folder in \OLDSYS
and when implementation is complete, place a short cut in the \OLDSYS folder that points to
the new location. This will allow people to quickly get to the new location.
Step 3 Pre-Classify the existing folder structure
1. Identify business area drives and their folders in a spreadsheet using List Generator utility
(3 levels is usually sufficient.)
2. Pre-Classify current folder structure to new taxonomy. Address areas of concern and look
closely at such folders and documents. Not all folders may need to be classified; this step is
merely to familiarize the team with the folders to be addressed. Work with the Business
Area administrative contact if necessary i.e. when classification issues arise.
3. Create the planned folder structures including a small draft series of common folders.
Typically this means folders for such common administrative items as budgets or employee
reviews. Also include a “_filing basket” folder and a “Z_Archive” folder. These will be the
first and last folders for each business area
Step 4 Prepare new location for business area
1. First a folder called X:\OLDSYS is created, marked as READONLY and the old folders copied
to this location. This allows the business area to retain the old system for a few weeks as
they move to using the new taxonomy. It creates a level of comfort but is only done when
size permits this duplication and is usually only retained for about a 4 week period. At that
time with the business area’s permission the OLDSYS folder is deleted.
2. Copy all current documents to this location – using existing file share where possible. (as
3. Request Systems/IT to set permissions for \OLDSYS to READ ONLY for all groups but
4. Copy all new system folders into the new location on the file server as \NEWSYS
5. Create a duplicate folder structure of \NEWSYS within Z_Archive
6. Create a duplicate folder structure of \NEWSYS within Z_Archive_destroy
7. Assign any modified permission groups to new folder structure. e.g. Role Based folders if
needed. Business Area should request application of any new security restrictions to these
Building a File Server Structure
Page 13
8. Provide an orientation session prior to implementation to each business area. This should
describe the process to be used and who should be present. A presentation is useful to
explain the process to staff. If it is a large business area … greater than 35 people, you may
wish to repeat the process with each distinct business group.
9. Ensure users are notified that implementation is taking place on a specific date. If staff are
on the drive or using a document during implementation, that document or folder may not
be accessible to the team.
All staff must be advised not to use the server while
implementation occurs. If they need a document they should copy to their personal folder
and once implementation is complete they can search for the documents new location and
replace it with any updates or edits.
Step 5 Implementation
1. Review (with all staff … as many as possible) current folders and move them to the new
classification structure . This normally will take several hours.
2. If new top level folders (records series) are created make sure that the taxonomy master is
updated. Also make sure that the new Z_Archive folders are updated
3. Move any outdated folders and documents to a Z_Archive folder (a designated archive
folder that employs the new classification structure) If classifying them would take too long
during this implementation meeting, place them in a filing basket and work with the
business area administrative contact at a later date to move them to the correct location.
4. Return any personal folders to appropriate locations on user drives.
Step 6 Disposition
1. Flag abandoned folders. If documents are transitory, they can be destroyed.
2. Define documents that have met their scheduled retention and move to Z_ArchiveDestroy
folder (Only if schedule is known at this time) This can be done at the end of
implementation and then every two years in conjunction with the business area
administrative contact and records management.
3. Delete any empty folders (samples)
Step 7 Post Implementation Tasks
1. Remove the \NEWSYS folder from a top level place by moving all the structure to its proper
position with the new top level structure. Delete the \NEWSYS folder (now empty)
2. Rename any sub folders to allow for better retrieval. Use naming conventions. Free
Commander has a multi-rename function.
3. Notify IT that NEWSYS is completed and request that IT provide updated Long Path
Detector report and the security information re Permissions list.
4. When staff are comfortable with the new system arrange the destruction of the OLDSYS
locked down folders to free up server space. Usually 2 – 3 weeks will be sufficient; coordinate this with IT and the business unit lead.
Building a File Server Structure
Page 14
5. Arrange for a one-hour orientation session for all staff so that they understand their roles
and responsibilities in naming documents or sub folders
6. Arrange for support to re-name folders or documents if time constraints made this
impossible during the implementation meetings.
7. The team will request that the Gr_Drive_Cleanup group to be removed from the drive
permissions. Wait a few months to do this, as the team may be called back to work on
8. Use List Generator to Inventory Z_ArchiveDestroy folders and date ranges for destruction
and attach to destruction authorization form.
9. Arrange for Destruction of Z_ArchiveDestroy folders.
Step 8 Post Implementation Review
The initial post implementation review of the pilot business units should identify significant savings
in time and productivity. Other key performance indicators should include improvements in
document integrity, fewer recreated documents, better version control, and even improvements in
business performance measures that can be attributed to improved access to and retrieval of
documents (improved response to public inquiries, for example). Additionally, there should be
reduced frustration of staff when dealing with e-documents. The project may wish to continue to
reassess key performance indicators or survey users during the period the implementation project
may take for all business units. (often months or years)
1. Check size of new drive structure and make note of the change in size to determine space
2. Repeat the original KPI survey to determine benefits.
3. Prepare a final report on benefits both quantifiable and subjective.
4. The organization should compare and contrast the results of business units by type and
function as well as identifying the totals of productivity gains.
Building a File Server Structure
Page 15
Can we really clean up file servers?
Much of the emphasis on taxonomies is driven by the need for an effective structure for Enterprise
Content Management Systems (ECM). A good taxonomy will inevitably lead to the success of an
ECM implementation. People will use a taxonomy that they have had input to, that management
has blessed and one that they understand. The anticipated productivity improvements of workflow,
project management and document retrieval will finally be achieved
Alberta Government. Naming Conventions for Electronic Records. August 2005.
Bibliographic Center for Research’s (BCR) BCR’s CDP [Collaborative Digitization Program] Digital Imaging
Best Practices Version 2.0 June 2008.
Brookhaven National Laboratory (BNL) Web Communication Standards. File Naming Conventions and
Directory Structure. February 5, 2008.
Digital Projects Advisory Group, University Libraries at the University of Colorado at Boulder. File
Naming Conventions for Digital Collections. March 4, 2008.
JISC Digital Media. Choosing a File Name. November 2008.
North Carolina Department of Cultural Resources. Best Practices for File-Naming. May 7, 2008.
UK National Archives, Guidelines on the realisation of benefits from electronic records management,
September 2004,
ealisation of Benefits from
Electronic Records
September 2004
Building a File Server Structure
Page 16
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF