Whether in your eDiscovery Projects, or
in your Information Technology lives, at some point you will become acquainted
with the Magic Number - 256. This number represents the Maximum Number
of Characters that a file name and its associated path can have in the
Microsoft Windows World.
Don't let this limitation be the New
Bullet that stops your ability to transfer, process, and ultimately
deliver data to your clients...
Problem:
Common Errors / Issues that you may see
when trying to access files that have a file name and path that is longer
than the 256 characters will include:
1. Error statements like: "Path
is too long", "The file name or extension is too long"
2. When you try to access the file through
Windows Explorer RIGHT CLICK Menu you notice items are missing...
3. Windows Explorer Properties missing
files from the file count. (Note: this screen shot shows 0 files because
there is only 1 file in the folder that I am using for this example)
Note: if you use another tool like Treesize,
then you see all of the files:
Depending on the applications that you
might be using, they may generate other error messages and allow you to
gracefully exit, or they may just crash because they loose access to the
file that they were trying to access.
Cause:
From the Microsoft Article referenced below:
"Win32 programs
are limited to a 256-character string size limit because of the MAX_PATH
variable. Software programs can work around this problem by passing Win32
a path that is MAX_PATH or less."
IT Scenario:
Typically in the IT role, you might see
this occurring when you are trying to access data from the ROOT of a disk
system, and the users have created folders, and ultimately a file name
and path from a mounted network share; or when you are trying to access
a user's documents on their Laptop/Desktop and they have created a path
that is just too long.
Here is an example of a file name and path
that your users may inadvertently create because they store their documents
in the "My Document" folder.
Example: "My Documents\My
Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project
ABC - Letter to Department Heads - Upcoming Changes in Application Functionality
- Phase 1 - 2009-Aug-11.docx"
Length: 221 Characters
When you actually try to access this file
from the root of the hard drive (aka C:\) the path is really as follows:
"C:\Documents and Settings\Richard
Wessel\My Documents\My
Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project
ABC - Letter to Department Heads - Upcoming Changes in Application Functionality
- Phase 1 - 2009-Aug-11.docx"
Length: 262 Characters.
Similar examples for disk storage systems
(NAS, file servers) and how IT departments organize the Departmental and
User Share locations should be considered... The user stores all of their
files on the "P:" Drive (Personal Network Share assigned by IT
through the Login Script or Windows Account settings), and they again build
a very deep and elaborate folder structure.
Example: "P:\My
Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project
ABC - Letter to Department Heads - Upcoming Changes in Application Functionality
- Phase 1 - 2009-Aug-11.docx"
Length: 224
When the Network Administrator tries to
access the file, they access it from the root of the file server, where
the P:\ drive is replaced by the full path that it was mapped to:
"R:\User
Data\Department A\Richard Wessel\My
Documents\My Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project
ABC - Letter to Department Heads - Upcoming Changes in Application Functionality
- Phase 1 - 2009-Aug-11.docx" Length: 262 Characters.
eDiscovery Scenario:
If you're working on an eDiscovery project
and you receive data from a client, you may also encounter this issue,
depending on how the client collected the data. (Keep in mind that the
same examples shown above in the IT Scenario may also be encountered in
an eDiscovery project if you are receiving images of computer systems (using
Encase, or other forensic imaging products) and the users have created
deep folder structures).
A basic scenario, may be that a company
is asked to collect all information for 5 custodians. The IT team at the
company gets involved and identifies all of the potential locations/sources
of data and then decides to organize it in an appropriate file structure
as follows:
Legal Project\Custodian A\Laptop\.....
Legal Project\Custodian A\Personal Network
Share\....
Legal Project\Custodian A\Shared Data from
Network\....
Legal Project\Custodian A\Email from Server\...
Just by using this directory structure
alone, the IT team is potentially adding anywhere from 34 - 51 characters.
Now this data is provided to an eDiscovery
Vendor, or the Law Firm representing the company, and they transfer the
data to their systems where they have a policy on Client Data and how/where
it is stored. Their policy may state something like: "Client data
is stored in a separate dedicated Source folder located in the Client's
Case Folder". So, when they transfer the data they organize it in
the following folder:
Client\CaseID\Source\....
Using this example, the Law Firm adds another
21 characters.
Just to put these numbers in perspective...
If we start with the very first example above, where the user had the data
stored in his "My Documents" folder,
Example: "My Documents\My
Business Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project
ABC - Letter to Department Heads - Upcoming Changes in Application Functionality
- Phase 1 - 2009-Aug-11.docx"
Length: 221 Characters
The IT Department would have placed this
data in the "Legal Project\Custodian A\Laptop\" Folder:
"Legal
Project\Custodian A\Laptop\My
Documents\My Business
Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project
ABC - Letter to Department Heads - Upcoming Changes in Application Functionality
- Phase 1 - 2009-Aug-11.docx"
Length: 254 Characters
The Law Firm would have placed this data
in the "Client\CaseID\Source\" Folder:
"Client\CaseID\Source\Legal
Project\Custodian A\Laptop\My
Documents\My Business
Documents\Global Projects\Project ABC\Internal Correspondence\2009\Management\Project
ABC - Letter to Department Heads - Upcoming Changes in Application Functionality
- Phase 1 - 2009-Aug-11.docx"
Length: 275 Characters
With a file name and path length of 275
characters, a number of the eDiscovery Vendor's or the Law Firm's tools
may have issues, and delay processing of the data...
Data Transfer Workarounds:
There are workarounds to allow you to gain
access to the data without encountering these errors specifically:
1. How the Folder Structures are designed
for transfer
2. How the data received is transferred,
and at what Folder level is the data transferred from/to
3. As mentioned in the Microsoft Article:
"On the server that contains the long directory structure, access
these files and folders through a local redirection ("net use"
or "subst") of the same share/folder that the network clients
access across the network." - This really means MAP a Drive to
a Point further down the Folder Structure so that you can access the data,
and then use this new mapped drive to work with and process everything.
4. As further mentioned in the Microsoft
Article: "In Windows... Explorer, select the folder one level above
the folder that returns the error. Right-click the folder returning the
error and then click Rename. Rename the folder to reduce the number of
characters used in the folder name." - WARNING: This implies that
you are going to be changing the original data and this may be an issue.
In these workarounds, there maybe other
considerations that you may need to take into account, especially if this
is an eDiscovery project:
1. Chain of Custody / Process Documentation:
When data is transferred the Chain of Custody should be updated and maintained
to reflect what was really done to the data
2. If you're renaming folders/sub-folders
to try to address the issue, you may be changing critical information that
may affect the meaning of the importance of the data. For Example, if the
folder you rename was called "Project ABC - Smoking Gun Documentation"
and you changed it to be "Project ABC - Smoking", the meaning
of the content of the folder totally changes.
3. If you're mapping network drives to
be able to access the data for processing, you need to ensure that you
document the drive mapping, and determine how it will affect your processing
strategy and how all of the data will again be consolidated into the appropriate
deliverable for the client.
In the end, anything that you do to the
data to get it transferred, accessible, processed, and ultimately provided
to the client needs to be properly documented.
UPDATED: 1/20/2010 @ 3:05
pm EST: Thanks to Jeff, who passed on this information to me: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath "The Windows API
has many functions that also have Unicode versions to permit an extended-length
path for a maximum total path length of 32,767 characters. This type of
path is composed of components separated by backslashes, each up to the
value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation
function (this value is commonly 255 characters). To specify an extended-length
path, use the "\\?\" prefix. For example, "\\?\D:\<very
long path>". "
So, I quickly Tested my Existing
Test Folder that I was looking at, and tried navigating using "\\?\"
Prefix, however it did not work within my test environment, as the application
(aka Windows default RUN Command, and Windows Explorer) may still be restricted
to the 256 character limit. It may be possible within the physical application
code to have vendors support this particular feature to be able to gain
access to the data.
There's more: Although you have probably read this, and
said "No one will ever use file paths and names like that...",
I have personally experienced this in working with a number of legal projects
where I was the IT person performing the identification and initial collection
of the data, and as an eDiscovery Consultant working with Vendors to process
data for clients.
You may not encounter these issues subject
to the Actual Data, How/Where you transfer the Data to your Systems (if
you transfer it instead of accessing directly from the original source
media), and the Tools that you are utilizing and their own limitations
(if any).
Another area where you may encounter this
issue is when you begin to look at compressed files that users may have
created. (meaning WINZIP. WINRAR and other compressed file formats). Some
tools extract\expand these file types, with the Folder structure contained
within the WINZIP/WINRAR being added on...
For Example: My Documents\My Business
Documents\Project ABC.ZIP
Depending on how the information was ZIP'd/RAR'd
the full folder path may or may not be included...
WinZip Settings:
WINRAR Settings:
This may mean that when fully expanded
the path might look something like this:
My Documents\My Business Documents\Project
ABC.ZIP\subfolder1\subfolder2\document2.docx
or
My Documents\My Business Documents\Project
ABC.ZIP\c\documents
and settings\My Documents\My Business Documents\Project ABC\subfolder1\subfolder2\document2.docx
Furthermore keep in mind that a Zip file
may be moved around by the users, and the original path may be totally
different then where the ZIP file currently sits.
In Closing:
The examples above may seem a little too
obscure, but they were developed to show the potential issue, and what
might happen when you are working with the data that is based in many folders/sub-folders
and has extremely long file paths and file names.
Vendors are continuing to develop and adjust
their tools to try to address these issues. eDiscovery Vendors who have
encountered these types of issues should have procedures in place to address
them.
If you haven't been thinking about this
as a potential issue, it may be something that you need to look at further,
a review of the information being provided as part of your Chain of Custody
may be required so that you can ensure that all the data provided to you
is being properly transferred, and ultimately processed.
Posted by Richard Wessel At 10:57 AM Location REW Computing Office | Permalink
| Comments (2)
10/21/2009
Who's On Your Legal Litigation Preparedness Team?
Tags: EDiscovery In
the Modern Age of Movie Making, everyone is striving for that next Oscar,
or Film Festival Award... To reach that goal, you need a team... In this
post, let me draw comparisons to the Movie Industry and the Roles involved
and compare that to your Legal Litigation Preparedness Team...
The Directors, Executive Producers In any production, the Direction of the
Project comes from the Director and Executive Producer, so in the Legal
space this would be coming from:
- The Plaintiff or Defendant… which typically
includes Corporate Counsel and key business unit contacts. Key Business
Unit Contacts typically are key people in the corporation that have an
internal knowledge of the matter at hand For Example the President, Vice
President, or a Project Manager, regardless they’ll be identified to you
by your corporate general counsel. And They’ll vary from company
to company.
- Legal Representation: which is typically
the external law firm
The Actors In any production, the Actors are typically
front and center, in our legal team, this would include:
Supporting Corporate Resources:
- Human Resources – They can provide you
the corporate policies
- Information Technology – If there is
an eDiscovery Component, this team will be critical to your understanding
of the computer environment and potential scope of data available to you.
They will provide you with Information on Backup Systems, and the Tape
Retention Policies.
- Records Management - They can provide
you with the Records Retention Policies; and the Records Classification
Specifications.
Litigation Support Teams
- Corporate Resource
- External Counsel Resource
Project Manager / Case Managers
- Internal Corporate Resource
- Litigation Support Resource
- eDiscovery Vendor Resource
Specific to Project Managers / Case Managers:
I would like to suggest that it is important that this role be of
utmost importance as inevitably you will want to know what the Status is
of various aspects of the legal matter. At a minimum you should ensure
that any Vendor that you are working with provides a contact that will
be your gateway to status updates and their issue resolution process during
the time that you have them engaged.
The Special Effects Team With Direction coming from the Corporate
and External Counsel; The Actors are executing the script and strategies;
There comes a time when some sort of Special Effect will be required…
this would include:
Vendors
- eDiscovery
- Forensic Collection
- Data Restoration Service Providers
- Etc…
Legal Consultants are typically experts
in a specific field or area of law, and can be engaged to help in addressing
key issues or decisions that you may need to address as part of your legal
matter.
Third Party Vendors play a critical role
to providing specialized services that address specific tasks where there
is Electronically Stored Information (ESI) involved. You will likely need
to have one of these involved through out your matter; Whether it be for
Processing and Producing Data; Collecting the Data; or Just getting the
data restored from the various Backup Media; these vendors will typically
provide an important service that you will be relying upon for the rest
of the matter.
Putting it all together The key Point…. You Can’t do it all by
yourself, you need a team to assist. Only together can the Directors, Executive
Producers, Actors and the Special Effects Team put the final product together.
After setting up this team and working
successfully to the conclusion of any legal matter, you should strive to
keep the team together, so that:
- You Don’t have to Re-invent the
Wheel - meaning that you should learn from what you and your team just
did.
- Your Team Understands: the Data
Universe; the Company Policies; a Litigation Hold Process; and a Data Collection
Strategy.
From each legal matter that you team works
on you should look to record any: Lessons Learned; Changes to the Policies,
Processes or Overarching Strategies that you may have followed, so that
you are prepared for the next time.
For more information on building your team
look at the following previous posts:
Posted by Richard Wessel At 9:59 PM Location REW Computing Office | Permalink
| Comments (3)
10/05/2009
Have you got your plan???
Tags: EDiscovery With
the New Rules of Civil Procedures for Ontario coming into affect in January
2010, one of the key changes is related to your DISCOVERY PLANS... Key
items: they must be in writing, and they must be agreed to by all parties;
there are time constraints on the production of the plan; there are content
requirements; the plan needs to be maintained/updated as things change;
and finally there is a potential penalties for not agreeing to / updating
the plan. ( See Rule 29.1 at http://www.e-laws.gov.on.ca/html/source/regs/english/2008/elaws_src_regs_r08438_e.htm
)
In addition, with respect to eDiscovery,
the Sedona Canada Principles need to be taken into account. ( http://www.lexum.umontreal.ca/e-discovery/documents/SedonaCanadaPrinciples01-08.pdf
); the principles all apply to any eDiscovery matter, however I want to
draw your attention to a few that really relate to the topic of developing
a plan between parties:
Principle 4: Counsel and parties
should meet and confer as soon as practicable, and on an
ongoing basis, regarding the identification, preservation, collection,
review and production of electronically stored information.
Principle 8: Parties should
agree as early as possible in the litigation process on the format
in which electronically stored information will be produced. Parties should
also agree on the format, content and organization of information
to be exchanged in any required list of documents as part of the discovery
process.
Principle 9: During the discovery
process parties should agree to or, if necessary, seek judicial
direction on measures to protect privileges, privacy, trade secrets and
other confidential information relating to the production of electronic
documents and data.
Principle 2: In any proceeding,
the parties should ensure that steps taken in the discovery
process are proportionate, taking into account
1. the nature and scope of the litigation,
including the importance and complexity of the issues, interest and amounts
at stake;
2. the relevance of the available electronically
stored information;
3. its importance to the court’s adjudication
in a given case; and
4. the costs, burden and delay that may
be imposed on the parties to deal with electronically stored information.
In a nutshell.... Meet and Confer and Agree
on what is the scope, formats, data exchange protocols, data protection
measures, and the level of effort being put forth to execute the discovery
plan is appropriate.
Your plan cannot be developed in the dark,
you need to work with your litigation preparedness team, and understand
the data that you have available to you. For more information on these,
refer to my previous posts:
ONTARIO REGULATION 438/08 made under the
COURTS OF JUSTICE ACT
Made: December 3, 2008
Approved: December 10, 2008
Filed: December 10, 2008
Published on e-Laws: December 12, 2008
Printed in The Ontario Gazette: December
27, 2008
Amending Reg. 194 of R.R.O. 1990 (Rules
of Civil Procedure)
http://www.e-laws.gov.on.ca/html/source/regs/english/2008/elaws_src_regs_r08438_e.htm
Posted by Richard Wessel At 8:39 PM Location REW Computing Office | Permalink
| Comments (1)
07/17/2009
Do you have your "A-Team"???
Tags: EDiscoveryGeneralIT Project Management The
A-Team, from the 1980's... This was "the" team to be on, they
rescued everyone, they caught the bad guys, and everything was neatly wrapped
up in 45 - 48 minutes (unless it was a two part episode). What I
would like to draw your attention to is the need for you to have a team
for all your projects, whether it is an IT Project, a Legal eDiscovery
Project, or even a Home Renovation.... You need to make sure that you have
the right people for the job. So, what are some things that you should
look for in your team?
1. Knowledge - Having the right skill
set is important; you need to have people that know the scope / impacts
/ methods / standards / etc that will help to make your project a success.
2. Experience - Just because someone
"knows" something doesn't mean that they actually know how to
implement or execute their particular tasks. (But keep in mind that everyone
needs to start somewhere - So keep the scope and type of project in mind
and you might just find that the new-kid-on-the-block is the perfect fit).
3. Initiative - Although you want your
team to work together, it may take someone to initiate and spark the project
into motion when things seem to be slowing down or starting to drift from
the original project scope. Keep in mind that "too many cooks in the
kitchen may spoil the soup". But if your team waits for you or the
project manager to explicitly tell them what to do for every little step
of the project, it will prove to be very trying and stressful
4. Energy - It is imperative to keep
a project moving, although "slow and steady wins the race", if
your overall project is slow and lethargic, your team will miss its opportunity
to bring value and change to your organization in the time frame that was
allocated.
5. Commitment - You can't do it all
by yourself... you need a team that is committed to seeing the project
through to its completion. Some examples of showing commitment include:
attending meetings; completing tasks on time; actively participating in
the project (if your team is "sitting on their hands", or "asleep
at their desks" it may be time to shake it up a bit). Another factor
to consider relates to the team members commitments outside of the workplace.
I don't mean that they have other things that they need to do, but rather
that they are committed to trying to maintain a positive work-home-life
balance.
6. Accountability / Responsibility -
Similar to Commitment (above) your team members need to take responsibility
and be accountable for their actions and participation within the team.
Following up and completing assigned tasks and doing what they say they
will do, all lead to an effective team that will be successful.
7. Suitability to the project - Look
at who you need within the team... If your project is Information Technology
related you would want to make sure that you have someone from the IT Department
on it... Likewise if your project has a large financial cost or accounting
impact, you may need to have someone from the Finance Department. Something
that I have personally seen overlooked in a few projects (during my employment)
is the missed opportunity to have the actual user community represented...
A good example of this came from my application development roles; we had
application champions that were responsible for the application and any
changes in its function... occasionally I would receive requests to make
changes from the champion, only to have to undo the changes after the user
community had a chance to test the changes before being rolled out. If
even one of the key power users of the application would have been consulted
during the champions re-design we would have not seen this issue and the
project would not have been delayed, or needed to be re-designed.
This is NOT a complete list and there
are many other things that you might look for. These seven items play a
major role in larger projects where the: stakes/risks may be higher; time
frame for implementation / execution is longer; scope is across multiple
departments or segments of the company.
To quote the A-Team: "I love
it when a plan comes together!" Col. John "Hannibal"
Smith (George Peppard) and "I pity the fool!" Sgt. B.A. "Bad
Attitude" Baracus (Mr. T).
In closing, work to make your team the
best it can be... your project depends on it.
Posted by Richard Wessel At 10:00 PM Location REW Computing Office | Permalink
| Comments (0)
07/08/2009
Don't Gamble with your Ediscovery - Understand the Process
Tags: Ediscovery Yes, I am a Trekkie! At the Beginning
of July 2009, I had the opportunity to take my wife to Las Vegas for a
few days without the kids... We had lots of fun and had a very restful
time.
As I look back on that trip now, I think:
"I was lucky I only lost $50.00." Wouldn't it be nice if
our legal matters only cost us $50.00?
There have been numerous articles and
white papers on Electronic Discovery and its costs and the need to control
and understand them. I want to suggest that although cost is important,
it is also important to understand what you are getting as part of the
eDiscovery service that you are paying for. And when I say understand,
I don't mean from a pricing proposal perspective, but rather from the process
that the vendor is going to follow.
Here are a bunch of examples / questions
that you might want to ask:
- Do you want the vendor to have
a certified process that they follow?
- Do you want to be able to get
reliable reporting and status from the vendor?
- Although you may NOT understand
the TECHNICAL aspects of everything that the vendor is going to do; do
they provide an opportunity for you to learn about their process and what
they do?
- Do they provide you with documentation
or summary report(s) of what they did?
- When they are asking you for
decision points, are they providing detail that helps you to understand
the impact and the risks associated with the decisions that you are making?
- Do you have a dedicated contact
person at the vendor that is available for you to contact at any time?
In the End, don't just throw away your
money, as if you are sitting at a slot machine; the slots are fun and loosing
a bit of money is ok when you're focused on the "entertainment"
of playing... But, in a legal matter we can't "play" with our
money, the costs are real, and you want to ensure that you are working
with a vendor that is doing everything in its power to ensure that you
receive a quality product that follows a repeatable process.
Want to find out more on selecting an
EDiscovery Vendor? You can Google "eDiscovery vendor checklist"
and you will receive a number of documents back... Here are a just a few
that I found useful:
It doesn't matter what the project, what role your playing, what company
you work for... the message is still the same. You need to document what
your doing. If your working towards any of the ISO Certifications (http://www.iso.org)
you should keep the following motto in mind: "Do as you say. Say as
you do"
I have been involved in a number of projects where documentation is key,
and yet when it came down to the wire, the documentation was incomplete
and missing. Not only did this add undue risk to the situation, but it
also quickly made team members look like they had not completed their tasks.
So, Here are some tips that may be of use to you:
1. Update Documentation IMMEDIATELY following any changes. If you have
a Help desk or an Issue Tracking system, you could integrate a "Documentation
Updated" check or a new status - "Resolved - Pending Documentation"
to indicate that the issue has been corrected, but that you still need
to complete the documentation.
2. Periodically Review documentation to make sure that any recent changes
have not gone un-documented.
3. If you have a Help Desk, or an Issue Tracking system you could look
at generating some report(s) that highlight the changes for a particular
system/application, and then use it as a checklist for ensuring that the
documentation has been updated.
4. Set up a documentation task force, and select systems/applications that
are critical to your organization. Assign specific documentation (by type,
role, or other means) to individual team members and set realistic timelines
that will allow the entire team to be successful. (Note: having a timeline
of 1 year is not an appropriate timeline. It needs to be measurable, and
assist with keeping the team members on track, and accountable).
5. Get management's support, communicating to them on a regular basis on
the status of any documentation initiatives.
6. Develop Templates that allow team members to start documenting and not
worrying about formatting. Consider developing a template for each of these
apps: Microsoft Word, Powerpoint, Excel, Visio.
7. Encourage the use of graphics, flowcharts, etc... Remember... A picture
is worth a thousand words.
8. Develop a standard set of definitions that will help to ensure that
team members are providing the same type/content for the same types of
documentation. (eg: System Management vs. User Management vs. System Monitoring,
etc)
9. If your having problems getting started, consider performing a brief
interview with team members to capture the current state of a system/application
and then use those findings to generate a list of documentation deficiencies.
10. When you are making changes to documentation make sure to track what
you changed in a "Revision History" or "Version Control
Table".
Posted by Richard Wessel At 7:15 PM Location REW Computing Office | Permalink
| Comments (2)
06/06/2009
File Type Summary - FTS
Tags: EDiscovery
When working with a data for
an Electronic Discovery project, clients usually ask... "What does
my data look like?"
This simple question has a number of responses... it can be as simple as
saying: "The data is comprised of 1045 files with a total size of
1.08 gigabytes." or better yet, the response is more detailled and
looks at the following things: Native Files (ie: Microsoft Office files),
Compressed Files (Winzip, Winrar, GZip, CAB, etc), Email Files (Microsoft
Outlook EML, MSG, PST and OST, Microsoft Outlook Express DBX, Lotus Notes
NSF, Other POP3/IMAP4/MAPI Mail formats, Microsoft Exchange EDB/STM Files),
Backup File types (Typically Windows Backup BKF), and Known System Files
(NIST).
A Detailed File Type Summary based on just the Extensions of the files,
is a good starting place, however, there are users that do not necessarily
conform to the default file naming extension practices that the newer releases
of software provide by default, and they will change the extensions. A
good example of this is when you think back to Wordperfect 5, 5.1, 6, etc...
it was common practice to name a "Memo" as ".MEM" or
a "Letter" as ".LET". So, depending on your users and
on various software packages used through the dates involved in the litigation,
it may be necessary for you to determine the true file type / format of
files that are named with non-standard extensions.
Other considerations that may be important, is whether you should be extracting
the Compressed Files and the Backup Files to their full original content.
Email Files can be extracted to MSG/EML format to provide detailled analysis
of the number of messages and attachments that are part of the collection.
Some Email files need to be converted to a supported format (e.g. OST and
DBX files need to be converted to PST).
Removal of "Known System Files" helps to reduce irrelevant documents
and the total costs related to processing. A number of tools integrate
the NIST Databases into themselves, so that any registered application
executable / dll / library / etc will be removed from your data collection.
To learn more about NIST, visit: http://www.nsrl.nist.gov/
Posted by Richard Wessel At 3:19 AM Location Prague Czech Republic | Permalink
| Comments (2)
09/16/2008
Data Centres: Getting Ready to Move your computers from one location to another...
Tags: IT Project Management
Over the Years, Companies will
find that their Computer Rooms (aka: Server Rooms, Data Centres, or any
physical location where a Computer is located) become to small for the
amount of equipment that they are housing in it.
Depending on the company's
direction, there may be opportunities to:
- consolidate servers (using
Virtualization Technologies like VMWare);
- replace older, bigger, and
slower servers with newer, smaller and faster ones;
- move the equipment to a
newer and bigger location
In this Blog, we will focus
on the Last option - "move the equipment to a newer and bigger location".
Like any project you first
need to look at:
- what exactly you are going
to be doing - setting the goals and objectives
- communicating with Team
Members, Managers, and Executive Management
- developing the plan, identifying
the steps, risks (impact to company, clients, vendors, etc),
- determining the required
resources (manpower / hardware / software / telecommunications / networking
/ co-location, etc) and the costs associated.
- determining the schedule
(not just implementation, but also key milestone dates).
What has worked well for REW
Computing is the following approach:
Initial Project Meetings
/ Interview: A meeting is held with the
Key Players / Decision makers and review the initial goals and objectives.
Use this opportunity to also inquire about costs and their expectations.
In some companies you may be told to do it as cheap as possible, and in
others you will be told that the risk of having the re-location fail is
too high, and that money is not an option.
Getting the Required Information: Working with the IT Team,
we request the following types of documentation:
- Physical Server / Network
Switch / Disk Systems / Other Systems Physical Rack Layout within the Existing
Computer Room.
- Network Diagrams and Physical
Port Configurations (Telecommunication Links, and Network Routers / Switches
/ Firewalls)
- Existing Computer Room Configuration
Details (eg: Current Cooling, Fire Suppression Limits, etc)
- Physical Server / Network
Switch / Disk Systems / Other Systems Environmental Specifications (Heat,
Power, Cooling, etc)
- Work with the appropriate
vendors to get additional information or reccomended strategy for moving
equipment.
Defining the Risk: Once you
have all of the information, you should be able to identify the key systems/servers
that are Critical (must have up and running) vs. Low Risk (move them but
if they are not up and running it's ok, we can have a few days to work
on them after the physical move).
Developing the Plan and
Determining Costs to Implementation: After the meetings and getting
all of the required information, a staged approach is developed to outline
exactly what needs to be done. Initially this plan starts off as high level
bullet points, but as it grows and is refined it becomes a detailed step
by step record of what needs to be done.
Other Documentation that gets
created includes revised through out all the phases include (but not limited
to):
- Network Diagrams
- Computer Room Rack Layouts
- Timelines
- Migration Plans for New
Hardware / Systems
- Test Plans to ensure equipment
/ applications / access
- Communication Plan
Through out the development
of the plan there are meetings with team members (internal and external
vendors) to ensure that the plan is sound and the timing is appropriate.
As each section of the plan is expanded and defined, any Costs associated
are also incorporated into an Executive Summary that will be presented
to gain final Approval.
Final Approval Meeting: Another meeting with the Key
Players / Decision makers is held and the entire plan and associated costs
(and Options) are presented. The goal of the meeting is to get final agreement
and approval to move forward with the purchase of any equipment / services
required. Upon Approval purchase orders are written and signed off
and submitted to the vendors.
Pre-Implementation Planning: With the approval given and
the Purchase Orders submitted, we continue to revise the detailled plan
and timelines for implementation. Working with the Team we will notify
affected clients of the schedule maintenance and start notifying Critical
Accounts with as much notice as possible. During this teim we also await
the delivery of any new hardware.
Implementation: Once everything is received
and the Time arrives to perform the move, complete the testing and execute
the communication plan to let clients / users know what happened.
There may be applications
/ services / servers that do not work after the move. Determine the Risk
associated with having the server unavailable and decide what the action
plan should be (ie: High Risk: need to address immediately; or Low Risk:
can continue to operate without this but needs to be addressed within 5
Days)
Post Implementation: Review what happened, what
worked, what didn't. Develop Lessons Learned that can be used in the future
for the next move. Review all documentation and ensure that everything
is updated and finalized. Have a Post Implementation Meeting with the Key
Players / Decision makers and review everything that happened. Review any
outstanding items that need to be completed and ensure that the plan and
timeline is in place to complete.
Posted by Richard Wessel At 1:17 AM Location REW Computing Office | Permalink
| Comments (2)