We are moving to www.clusterwin.blogspot.com

Dear all,

  We are moving to www.clusterwin.blogspot.com. Existing subscribers/Viewers please subscribe to our new Blog. The current blog will no longer available on April firtst week onwards

Thank you

Cannot change Desktop Background Changing Option in windows 7

                                         

Release

Windows 7

Problem

“This image can't be set as wallpaper. An internal error occurred”.

Causes

v  Corrupted TranscodedWallpaper.jpg

v  There are third-party applications like Display Manager from Samsung. (Resolution, uninstall)

v  The Remove background images option is incorrectly checked

v  Domain policy disables the background changing

Solution

Sometimes you cannot change your desktop wallpaper in Windows 7. For example, you see a black background even though you change your background picture. Another instance is, when you try to right-click a picture and then select ‘Set as desktop background’, you will get an error message “This image can't be set as wallpaper. An internal error occurred”, etc.

Ø  Start à Run à type %USERPROFILE%\AppData\Roaming\Microsoft\windows\themes ->enter.

     

Ø  Delete the file TranscodedWallpaper.jpg.

Error message when you try to perform a system state backup in Windows Server 2008 and Windows Server 2008 R2

When you try to perform a system state backup to a volume on which the system state file resides, you receive an error, as mentioned below:


In Windows Server 2008, you receive the following error:
ERROR - The location for backup is a critical volume.


In Windows Server 2008 R2, you receive the following error:
ERROR - The backup storage location is invalid. You cannot use a volume that is included in the backup as a storage location


This behavior occurs because system state backups to critical volumes are blocked in 
Windows Server 2008 and Windows Server 2008 R2.


You can change the default behavior of Windows Server 2008 and Windows Server 2008 R2 by adding a registry entry. You must also verify that the following prerequisites are met before you perform a system state backup to a critical volume.



Prerequisites to perform system state backups to critical volumes


Make sure that the target volume has no shadow copy before the backup starts.


If a system state backup is stored on a source volume, backup settings should be configured for full backups. By default, settings are configured for full backups.


Periodically check that no other user or program maintains a shadow copy on the target 
volume.


Do not keep volume level backups and system state backups in the same location.


The volume used to store the system state backup needs twice the amount of free space as the size of the system state backup until the backup completes.




Notes


Any writes on target volume with shadow copies will increase the diff area size. 


If the diff area is bounded, it may cause deletion of shadow copies.




Incremental backups leaves shadow copies behind, it will cause side effect as point 1.


Backup stores different versions as shadow copies, it will cause side effect as point 1.



Registry entry to enable system state backups to critical volumes




To enable the system state backup files to be targeted to critical volumes, you must set the


 value of the AllowSSBToAnyVolume registry entry under the following registry subkey:




HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\


Set the value of this entry as follows:


Name: AllowSSBToAnyVolume


Data type: DWORD


Value data: 1


Note When this value is set to 1, system state backups to any volume are enabled. To revert


 to the default behavior, set the value to 0.

Exam 70-642: TS: Windows Server 2008 Network Infrastructure, Configuring MCITP Brain Dump

Click the below link for Exam 70-642: TS: Windows Server 2008 Network Infrastructure, Configuring MCITP Brain Dump

                           www.mediafire.com/?rsk9csdsu8lu779

RHCE interview Questions

FOr RHCE Interview Questions please click below link

http://www.studentcpu.com/2009/09/linux-string-processing-command-less.html

The ext3 file system in Linux

The ext3 filesystem, developed by RedHat extends the popular ext2 filesystem with the introduction of journaling.

What is a Journaling Filesystem?

A journaling filesystem keeps a journal or log of the changes that are being made to the filesystem during disk writing that can be used to rapidly reconstruct corruptions that may occur due to events such a system crash or power outage. The level of journaling performed by the file system can be configured to provide a number of levels of logging depending on your needs and performance requirements.

What are the Advantages of a Journaling Filesystem?

There are a number of advantages to using a journaling files system.

Both the size and volume of data stored on disk drives has grown exponentially over the years. The probelm with a non-journaled file system is that following a crash the fsck (filesystem consistency check) utility has to be run. fsck will scan the entire filesystem validating all entries and making sure that blocks are allocated and referenced correctly. If it finds a corrupt entry it will attempt to fix the problem. The issues here are two-fold. Firstly, the fsck utility will not always be able to repair damage and you will end up with  data in the lost+found directory. This is data that was being used by an application but the system no longer knows where they were reference from. The other problem is the issue of time. It can take a very long time to complete the fsck process on a large file system leading to unacceptable down time.

A journaled file system records information in a log area on a disk (the journal and log do not need to be on the same device) during each write. This is a essentially an "intent to commit" data to the filesystem. The amount of information logged is configurable and ranges from not logging anything, to logging what is known as the "metadata" (i.e ownership, date stamp information etc), to logging the "metadata" and the data blocks that are to be written to the file. Once the log is updated the system then writes the actual data to the appropriate areas of the filesystem and marks an entry in the log to say the data is committed.

After a crash the filesystem can very quickly be brought back on-line using the journal log reducing what could take minutes using fsck to seconds with the added advantage that there is considerably less chance of data loss or corruption.

What is a Journal Checkpoint?

When a file is accessed on the filesystem, the last snapshot of that file is read from the disk into memory. The journal log is then consulted to see if any uncommitted changes have been made to the file since the data was last written to the file (essentially looking for an "intention to commit" in the log entry as described above). At particular points the filesystem will update file data on the disk from the uncommited log entries and trim those entries from the log. Committing operations from the log and synchronizing the log and its associated filesystem is called a checkpoint.

What are the disadvantages of a Journaled Filesystem?

Nothing in life is is free and ext3 and journaled filesystems are no exception to the rule. The biggest draw back of journaling is in the area of performance simply because more disk writes are required to store information in the log. In practice, however, unless you are running system where disk performance is absolutely critical the performance difference will be negligable.

What Journaling Options are Available with the ext3 filesystem?

The ext3 filesystem provides three options. These are as follows:

• writeback - greater speed at the price of limited data integrity. Allows old data to show up in files after a crash and relies on kernel's standard writebacks to flush buffers.
• ordered -  that the data is consistent with the file system; recently-written files will never show up with garbage contents after a crash at the cost of some speed.
• journal - Journals all data requiring greater journal space and reduced performance. The most secure data retention policy.

Does the Journal log have to be on the same disk as the filesystem?

No, the ext3 journal log does not have to be on the same physical device as the filesystem it is logging. On a RedHat Linux the journal device can be specified using the journal_device= option with the -journal-options command line argument of the tune2fs utility.

How to check Previous IP ADdress Details in windows Machines

How to check previous IP address details if customer not aware about it.

Release

Windows XP

Problem

After replacing motherboard customer not aware about previous IP address details.

Solution

In this case using registry we can find out previous IP address details, Windows Registry path should be specified below:

Current and previous IP address details will list under:

“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Prameters\Interfaces”