File Last Accessed

If you right click on any file, you can see the File Last Accessed value under the General tab. The problem is, that might not be up to date or might even report the 1st of January 1970 as last access date, even when you open and close the file.

FileLastAccessed_not_updating

Now that isn’t a great start if you want to audit files not accessed in a long time frame. That would be extremely helpful for File Servers as you would be able to provide reports to the Share’s owners. This will help them choosing the files that can be archived/deleted.

The reason why this is not updating by default is due NtfsDisableLastAccessUpdate [HKLM\SYSTEM\CurrentControlSet\Control\FileSystem] registry key that is set to 1 to prevent excessive writes to disk. This is Microsoft’s description about this REG_DWORD:
0: When listing directories, NTFS updates the last-access timestamp on each directory it detects, and it records each time change in the NTFS log.
1: When listing directories, NTFS does not update the last-access timestamp, and it does not record time stamp updates in the NTFS log.

Setting this key to 0 will allow the OS to start capturing the last accessed property. Another way to disable this registry key is running the following command with elevated rights:

In Microsoft’s words: Because updating the last-accessed timestamp requires writing data to the disk, an activity that accesses many files might be faster if this type of update is disabled.
I searched a bit more and also found out a user who noticed a 6% performance increase when this key was set to 1. When NtfsDisableLastAccessUpdate was set to 1, the backup took 5 hours and 45 minutes, when it was set to 0 it took 6 hours and 7 minutes (200GB worth of data).

Read More

Global Service Desk

helpdeskThis article is meant to give more attention to what I didn’t think was a big issue around the IT world: how to get the best our of your Global Service Desk team! I saw a question on LinkedIn where somebody was going to implement a Global Service Desk team and wanted some suggestions and also shared his fear about the possibility of Service Desk representatives leaving tickets in the global queue because “somebody else” will pick them up.

I was the first to answer the question, then over 120 other people did, so I started reading and reading as I was really curious what others thought. Many agreed with me, many gave extra arguments and some where bad comments such as “Don’t centralize it then!“. The problem is not only the fact that they were suggesting not to proceed with what I think it’s an improvement, but these comments were missing the reasons why they shouldn’t have done that. Note also that centralising a team doesn’t mean you have to have them in the same office! They can even be in different Countries.

So this article wants to try to grab all of the comments I found and put them together even though the main steps that somebody must follow to achieve this are pretty much two:

  • Get a Ticketing system in place, possibly a high-customizable one that will allow you to create Categories and Reports.
  • Get one or more Team Leaders/Managers depending on how big the team is.

There are many variables in play, so nobody will be able to describe a combination of scenarios that match your enviornment from an article like this one, but I can try to give a high level of ideas that will help you. One of the things I don’t know for instance is how many other teams you have (i.e. second level support, 3rd level Unix support, 3rd level Infrastructure support, Windows and so on). Let’s just say there’s one or more teams you’re able to escalate tickets to. (more…)

Read More