none
How to move Event viewer Logs to another drive connected to the system? RRS feed

  • Question

  • Is there a set of command lines or can I adjust the registry to set a new location to where I want the logs to be stored. I want the logs to be stored on the G: drive and not the system root of C: drive in Windows 7 Pro 64-Bit OS?
    Wednesday, June 23, 2010 2:26 PM

Answers

  • Hi, 

    OK, understand the requirement. 

    I have tried with a different location, but just now tried with a different drive. It worked without an issue. However, in my case it was the other partition in the same disk. Drive letter was D:. This is what I did.

     

    1. Created a folder D:\logs
    2. In event viewer, opened the properties of system events
    3. Changed the log path to D:\logs\System.evtx (though it says 'path', it should include the file name too.)
    4. Soon as I press 'Apply', it created the file in the path and used it (when I opened it directly I could see the current events)
    The only difference I can see in your system is that your G: drive is a RAID volume. I'm not sure if the RAID driver is not loaded at the time it starts writing eventlog. In my case it was a local disk so it should have been available at boot-up.
    I just tired creating it in my docs (C:\user\xxx\documents\logs) which didn't work. I couldn't dig deeper, but the possibility is that the access restrictions on user folders. If you were trying a similar location (or a path with linked names, spaces etc.), it is a good idea to try a simple root level folder.

    By the way, I'm curious. I thought the leveling techniques they use with SSDs take the write cycle issue away. Do you have any specific reasons to think that it's harmful? 


    Krish

    PS: I actually took a screenshot to show exactly what I have done, but then realize images are not allowed here :-(

    • Marked as answer by sprogis Thursday, June 24, 2010 11:34 PM
    Thursday, June 24, 2010 10:59 PM
  • You can use Group Policy.

    Computer Configuration | Administrative Templates | Windows Components | Event Log Service

    Under Application configure Log File Path

    Description:
    This policy setting controls the location of the log file. The location of the file must be writable by the Event Log service and should only be accessible to administrators.

    Repet this setting for System and Security logs.

    • Marked as answer by sprogis Wednesday, June 23, 2010 4:01 PM
    • Unmarked as answer by sprogis Thursday, June 24, 2010 4:04 AM
    • Marked as answer by sprogis Tuesday, June 29, 2010 2:49 AM
    Wednesday, June 23, 2010 2:56 PM

All replies

  • You can use Group Policy.

    Computer Configuration | Administrative Templates | Windows Components | Event Log Service

    Under Application configure Log File Path

    Description:
    This policy setting controls the location of the log file. The location of the file must be writable by the Event Log service and should only be accessible to administrators.

    Repet this setting for System and Security logs.

    • Marked as answer by sprogis Wednesday, June 23, 2010 4:01 PM
    • Unmarked as answer by sprogis Thursday, June 24, 2010 4:04 AM
    • Marked as answer by sprogis Tuesday, June 29, 2010 2:49 AM
    Wednesday, June 23, 2010 2:56 PM
  • Even though I could not do it this way. I'm sure it would work to.

    • Edited by sprogis Tuesday, June 29, 2010 2:50 AM change note.
    Thursday, June 24, 2010 4:07 AM
  • If you have to do it for a single computer, you can do it in the even  viewer itself.

    Run event viewer by typing 'event viewer' in the search box, then select the event log you want to change, go to properties with right click. There you can change the path to any location.

    Having said that, usually it is set to boot drive since it is always available. I'm not sure what's going to happen if your G: driver becomes unavailable or say if the drive letter changes. So don't change it unless you really have to  - they don't take much space anyway.

    Hope this helps,

    Krish

    Thursday, June 24, 2010 6:30 AM
  • You need to change the log not only for Application log, but also for other logs: Security, Setup and System. In Group Policy Editor, under Computer Configuration\Administrative Templates\Windows Components\Event Log Service, change the policy Log File Path for all the events.
    Arthur Xie - MSFT
    Thursday, June 24, 2010 9:11 AM
    Moderator
  • You are right. However, I 'm not sure how to make the new location writable by event log servie.  What I would like to do is move the hole event log system off the %root% C: drive to drive G:. Are you able to provide a step by step process.  I can't seem to find one yet. Please and thank you.
    Thursday, June 24, 2010 5:56 PM
  • The G: drive will always be apart of the system. Its really a partition on a RAID volume.  I have a system image to restore to if the RAID fails. I have included the G: partition in the system image for safe keeping. This is in an effort to reduse writes to the system Solid State Drive SSD. To extend the write cycles a lot longer in the long run. Event log service can store up to 4GB of space on a system drive. I don't need all those wasted write cycles for logs. Thank you very much for your support.  I am still having some issues with this, have you actually tried it?  If so to another drive location?.  I have done some checking andwith Windows 7 there is a security discriptor that I can't get around for now. To complicated and not enough step by step process for the learner. More pictures would be great on the web pages I did visit.
    Thursday, June 24, 2010 6:05 PM
  • Hi, 

    OK, understand the requirement. 

    I have tried with a different location, but just now tried with a different drive. It worked without an issue. However, in my case it was the other partition in the same disk. Drive letter was D:. This is what I did.

     

    1. Created a folder D:\logs
    2. In event viewer, opened the properties of system events
    3. Changed the log path to D:\logs\System.evtx (though it says 'path', it should include the file name too.)
    4. Soon as I press 'Apply', it created the file in the path and used it (when I opened it directly I could see the current events)
    The only difference I can see in your system is that your G: drive is a RAID volume. I'm not sure if the RAID driver is not loaded at the time it starts writing eventlog. In my case it was a local disk so it should have been available at boot-up.
    I just tired creating it in my docs (C:\user\xxx\documents\logs) which didn't work. I couldn't dig deeper, but the possibility is that the access restrictions on user folders. If you were trying a similar location (or a path with linked names, spaces etc.), it is a good idea to try a simple root level folder.

    By the way, I'm curious. I thought the leveling techniques they use with SSDs take the write cycle issue away. Do you have any specific reasons to think that it's harmful? 


    Krish

    PS: I actually took a screenshot to show exactly what I have done, but then realize images are not allowed here :-(

    • Marked as answer by sprogis Thursday, June 24, 2010 11:34 PM
    Thursday, June 24, 2010 10:59 PM
  • Thank you.  That worked great.
    Thursday, June 24, 2010 11:35 PM
  • Hi, 

    OK, understand the requirement. 

    I have tried with a different location, but just now tried with a different drive. It worked without an issue. However, in my case it was the other partition in the same disk. Drive letter was D:. This is what I did.

     

    1. Created a folder D:\logs
    2. In event viewer, opened the properties of system events
    3. Changed the log path to D:\logs\System.evtx (though it says 'path', it should include the file name too.)
    4. Soon as I press 'Apply', it created the file in the path and used it (when I opened it directly I could see the current events)
    The only difference I can see in your system is that your G: drive is a RAID volume. I'm not sure if the RAID driver is not loaded at the time it starts writing eventlog. In my case it was a local disk so it should have been available at boot-up.
    I just tired creating it in my docs (C:\user\xxx\documents\logs) which didn't work. I couldn't dig deeper, but the possibility is that the access restrictions on user folders. If you were trying a similar location (or a path with linked names, spaces etc.), it is a good idea to try a simple root level folder.

    By the way, I'm curious. I thought the leveling techniques they use with SSDs take the write cycle issue away. Do you have any specific reasons to think that it's harmful? 


    Krish

    PS: I actually took a screenshot to show exactly what I have done, but then realize images are not allowed here :-(


    On some SSD yes. With older Windows OSs yes. The problem is Windows 7 has adefault to overwrite events in event logs.  For Tirm to work corectly you have to send a delete command.  An overwrite command is not a delete and HDDs can overwrite very well.

     

    Here is my

    link http://www.guru3d.com/article/ocz-ve...-ssd-preview/5 Page 5

    This is taken from page 5 in the review.

    Windows 7 and the SSD TRIM feature

    TRIM only improves performance when you delete files. If you are overwriting an existing file, TRIM doesn't help and you'll get the same write performance degradation as without TRIM.


    This is a break down of Event Viewer in Windows 7.

    The defult space used on the SSD is 338.87MB = .339 GB and a default setting to overwrite events as needed, oldest first. To some people who need the logs could end up having as much as 4GB on the system SSD. Thats alot of overwritting if it goes unmonitored.

    Each log folder has a size amount to store log data, most being 1MB.

    Windows log Folder has 5 sub folders for log data.

    Application and Services Logs folder has 3 sub folders for log data.

    Windows folder has 120 log folders, each have sub folders for log data.

    Since the default in Event viewer is to "Overwrite Events as needed, oldest log first". Now understanding how the SSD controller works, you could imagine how the kb bits of log data is stored in the SSD nand? Note there are 120+ log folders to write data to and yes some logs are not used until needed. To simply put the controller has to much work to do when most of the logs get full. Not to mention the controller has to wait for NTFS bitmap updates for the now unused nand to be recovered by GC in an IDLE state.

    This is what maybe going on inside. A Windows log gets almost full, Windows sends an overwrite command and were does the controller put the log data that is to big at the time of shut down and or time of power on without NTFS bitmap updates and IDLE time for GC and or other method in the controller to recover SSD nand and where can Windows write the new data to be stored if the log is full?

    So instead, if you configure to one of the other options to manage how log data is saved. The controller will have less work to do from NTFSbitmap updates to the SSD.

    Friday, June 25, 2010 10:43 AM
  • Thanks a lot for this. Very useful info to know. I thought the write cycle issue is behind us, but doesn't seems to be :-)

     

    Krish

    Saturday, June 26, 2010 1:24 AM
  • You're welcome. Thanks to all of you for your help. Very much appreciated.

    Tuesday, June 29, 2010 2:49 AM