How to identify the user deleted iConect folder(s)?
Normally you will get contacted by a case team member if a user has deleted a folder from the case database. By then you will already know the name of the case, database, folder and user who deleted the folder. If the name of the user is not known, it is still possible to find out who deleted the iConect folder (from the front end) and when the folder was deleted.
What actions should be taken to restore the deleted folder?
Follow these steps precisely to recover the deleted folder. Incomplete &/or missteps will inadvertently lead to complications. Immediately contact your administrator if you have made a mistake.
STEP-1:
RDP to the iConect database server and locate the Folder Log Processor application (it will be an .exe file). Typically the location of this file is: G:\iconectnxt\iLETs\Tools\FolderLogProcessor\FolderLogProcessor.exe where
G:\ drive can be replaced by the relevant drive letter in your iConect environment.
STEP-2: Double click the Folder Log Processor
application and fill out the details as shown in the picture below. (Read STEP-3 & 4 to better understand how to provide details for FLP Application.)
STEP-3: Always make copies of the FBL files to your analysis folder.
-
FBL files are typically located in G:\iconectnxt\datafiles\logfiles\FolderLogs\ directory.
-
They are named by date, for example: 2011-05-11.fbl and 2011-05-11-Backup.fbl , etc…
-
If you already know the date range when the folder was deleted, it becomes easier for you to select and copy those .fbl files that fall under the date range of folder deletion.
-
Make sure that when you copy the .fbl file(s), you must always copy its corresponding backup files.
-
As a precaution, never work on the original .fbl file. Always make a copy. Not making a copy may lead to altering the original .fbl file which will not be appropriate for future traceability.
STEP-4: Fill the details for the folder logging application.
-
Click on source and point to the folder where you have made a copy of the .fbl files.
-
Select the date range of the folder deletion activity.
-
Select the destination folder where you want the output CSV file to be generated.
-
Select the name of the database where the folder deletion took place.
-
Finally, click the Convert Now button.
-
An output CSV file is generated in the destination folder.
STEP-5: Analyze the output CSV file.
-
The CSV file will look somewhat like this:
“Folder”,”User”,”Record”,”DB”,”DateTime”,”Operation”,”Checked”
“Unknown folder id: 400 in database: 221″,”mpeera”,”0″,”Doc Review DB”,”05/11/2011 07:52:47 PM”,”4″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”1″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”151″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”153″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”294″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”303″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”106722″,”Doc Review DB”,”05/11/2011 07:53:55 PM”,”8″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”106721″,”Doc Review DB”,”05/11/2011 07:54:01 PM”,”8″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”106720″,”Doc Review DB”,”05/11/2011 07:54:05 PM”,”8″,”1″
“Unknown folder id: 400 in database: 221″,”mpeera”,”0″,”Doc Review DB”,”05/11/2011 07:54:22 PM”,”7″,”0″
-
To understand how to interpret the CSV, lets define and describe each header field:
-
Folder: the ID of the folder and the ID of the database where the activity took place. When the value is specifically “Unknown folder id:……” it means that the folder was eventually deleted. In our example “Unknown folder id: 400 in database: 221″ means, the folder id 400 which eventually got deleted from database id 221.
-
NOTE:
In order to find out the id of the database use the troubleshooting tab on the nxtManager. -
User: username who took action on that folder.
-
Record: Oracle Record Number of the document that got added to that folder in the database. In our example it is folderid = 400 and database id = 221. Zero as a record number signifies that the folder was created but no documents were added to it.
-
DB: The name of the DB where the activity took place.
-
DateTime: Time Stamp of the activity.
-
Operation: Specific activity that was performed on the folder.
-
Checked: This field signifies whether document(s) were added or removed from the folder(s).
-
Refer the table below to better interpret various actions based on the Operation and Checked fields.
-
STEP-6: Prepare an overlay reference file.
-
Once you have identified which folder got deleted, who deleted it and when it was deleted, the next imperative step is to restore the folder in the correct case database.
-
You will have to manually recreate the folder under the correct tab and hierarchy.
-
Prepare a reference file which lists the OracleIDs of the documents that got deleted from the identified folder.
-
Note: Do not confuse OracleID with Rec#. They are different. See the picture below.
Note:
In some cases when the database has no deleted records, the Rec# and OracleID will always be the same. Always double check to see the last record. If all 3 numbers are the same then you can consider that the Rec# = OracleID.
What actions should be taken to correlate all the appropriate documents in the restored folder?
-
In cases where the Rec# and OracleID are the same, you can create a new field, match and mask a “Y” in that new field and search for all documents that have a Y in the new field that you created. After the search returns the results, mass folder those document back to the restored folder.
-
In cases where the Rec# and OracleID are not the same, manually add the documents to the resorted folder.
Posted on May 25, 2011
0