In a nutshell you run the md5 check on the source and destination server to validate the files haven’t changed or become corrupted in transit by comparing the output from md5sum.

There are a couple of ways you can use it.

1. Generate md5sum for a file or files:

   md5sum test

   This will return something like this:

   d41d8cd98f00b204e9800998ecf8427e  test

   Then by comparing the resulting output from the same md5 checksum on the source server you will know if the files are identical.

2. Create a file containing a list of previously created sums and use md5sum to validate that the sums match. E.g.

   sums.txt:

   d41d8cd98f00b204e9800998ecf8427e  test
   0d599f0ec05c3bda8c3b8a68c32a1b47  test2

   Execute md5sum passing in the file for checking:

   md5sum -c sums.txt

   md5sum returns OK for all sums that match:

   test: OK
   test2: OK

And it’s as simple as that. This can also be useful where you know you have multiple versions of files. Using the md5sum you can validate which version is where. This simple tool has saved my bacon a number of times on web servers and CDNs where files have been cached.

Windows cannot access the file gpt.ini for GPO CN={9937F003-8D5C-49E6-A36C-EE944E1A7962},CN=Policies,CN=System,DC=***,DC=***,DC=co,DC=uk. The file must be present at the location <;\\FQDN\sysvol\FQDN\Policies\{9937F003-8D5C-49E6-A36C-EE944E1A7962}\gpt.ini>;

The GUID in the error matched that of the GPO I had just created. As I started to investigate further I noticed that rsop.msc also returned errors:

“RSoP data invalid. Likely causes are, data is corrupt, data has been deleted or data has never been created.”

After checking the SYSVOL shares on each domain controller in the domain it was apparent that the policies files didn’t exist on all of the domain controllers. We had recently suffered a power cut and the DCs had not been shutdown cleanly. It dawned on me that no changes to GPO or other files contained with the SYSVOL share had been replicated since the power cut.

The event logs on the domain controllers contained several File Replication Service errors:

The File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.

Should FRS encounter journal wrap errors on a domain controller replication will cease to work until the error condition has been reset. (Since Windows 2000 SP3 these errors are no longer cleared automatically.) To reset the error a Non-Authoratitive restore of the data is required. This can be achieved by enabling journal wrap automatic restore through a registry change. As detailed below:

Note! As this is a non authoritative restore you could potentially lose data contained within SYSVOL. The SYSVOL will be rebuilt with data from other DCs in the domain.

1. Stop FRS.
2. Start Registry Editor – regedit
3. Locate the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters
4. Add the following registry value:
Value name: Enable Journal Wrap Automatic Restore
Data type: REG_DWORD
Radix: Hexadecimal
Value data: 1 (Default 0)
5. Quit regedit
6. Restart FRS.

After making the above changes and restarting FRS keep an eye on the event log and SYSVOL. After some time you’ll notice new entries in the event viewer as restoration of the SYSVOL begins to take place. And you’ll notice over time that SYSVOL once again becomes synchronised across all the DCs in the domain.

Of course the alternative would be a restore of the DC but that would remain a reboot into DSRM and a lot more downtime!

I finally stumped up the courage to take the exam on Friday and passed!! There was a huge sigh of relief when the message that I’d passed popped up at the end of the exam!! I really wasn’t looking forward to it. I’d worked out it was the first test of any kind I’d taken since leaving university some 9 years ago!

So with that out of the way I intend to post here a little more often. Although that said I intend to start studying for the next exam (70-642) pretty soon!

What you’ll need:

1. A server to run the script from
2. Something to execute the script – In my case the UPS activates the script when a power outage is detected. But, this could also be a cronjob or something similar
3. SSH access between servers. See this post to allow SSH logon without requiring a password to authenticate
4. The user you connect with should have permissions to execute /sbin/shutdown on the remote server

There are two parts to this script. First the script itself and secondly a text file containing a list of servers you wish to shutdown

The script:

PATH=/usr/local/bin
HOSTFILE=$PATH/servers
LOGDATE=$(date +%F_%T);
LOGFILE=$PATH/shutdown_$LOGDATE.log

for host in $(cat $HOSTFILE);do
echo "Shutting Down $host..." >> $LOGFILE
echo $(date) >> $LOGFILE
ssh -t alan@$host "sudo /sbin/shutdown -h now" >> $LOGFILE
echo "$host Shutdown" >> $LOGFILE
echo  >> $LOGFILE
echo  >> $LOGFILE
done

echo "Remote Shutdown Completed" | mutt -s "Remote Shutdown" -a $LOGFILE joebloggs@abc.com

When you execute the script it will loop through the list of servers stored in this text file:

server1
server2
server3
server4
server5
....

A simple log file is created showing the process, an e-mail is then sent with the log file attached.

Enjoy!

After running two simple commands you can SSH to a server without requring your username or password. The basic principal is to generate a public/private key pair which is associated with your user account. The public key is then copied to the destination server and used for authentication instead of your password.

In this example I assume you will be connecting from servera and connecting to serverb.

1. From servera you will need to run ssh-keygen. This generates the public/private key pair
   

   alan@servera$<strong> ssh-keygen </strong>Generating public/private rsa key pair.
   Enter file in which to save the key (/home/alan/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/alan/.ssh/id_rsa.
   Your public key has been saved in /home/alan/.ssh/id_rsa.pub

2. Use ssh-copy-id to copy the generated public key to serverb. This will append your public key to the list of authorised keys on the remote server in ~/.ssh/authorized_keys
   

   alan@servera$ <strong>ssh-copy-id -i ~/.ssh/id_rsa.pub serverb</strong>
   alan@serverb's password:
   Now try logging into the machine, with "ssh 'serverb'", and check in:
   
   .ssh/authorized_keys
   
   to make sure we haven't added extra keys that you weren't expecting.

3. Now try and SSH to serverb

   alan@servera$ <strong>ssh serverb</strong>
   Last login: Sat Jan 28 10:01:59 2012 from 10.30.0.155

Assuming you followed the above steps correctly you should now be able to SSH to your server without requring a password!

Since launch it all seemed to be working ok but after a little while I noticed that bookmarks weren’t updating correctly. And after trying various combinations of disabling and re-enabling bookmark sync on iPad, iPhone and in Windows it was apparent that nothing was syncing and I ended up with no bookmarks on iOS.

At this point I noticed this yellow warning triangle over the iCloud Control Panel icon. There was no explanation to this icon and I’ve not been able to find an error log, but, I could only assume this was related to bookmark syncing as everything else was working correctly.

The best method I’ve found to get bookmark sync working with Internet Explorer properly again is this:

1. Disable bookmark sync on all iOS devices
2. Disable bookmark sync in iCloud Control Panel
3. Sign Out of iCloud Control Panel
4. Move all favourites into a temporary location. This should leave you with no favourites in IE
5. Ensure your favourites are stored in the default location. Usual default for Windows 7 is C:\Users\[Username]\Favorites or C:\Documents and Settings\[Username]\Favorites for Windows XP – I read a comment on the Apple forums that suggested a greater chance of success if configured this way!
6. Sign In to iCloud Control Panel
7. Enable bookmark sync in iCloud Control Panel.
8. Restore your favourites back to the favourites folder.

After a few moments, you should find an Apple.plist file in each subdirectory of your favourites folders. I believe this file is how iCloud keeps track of your favourites and what needs to be synced. It’s presence seems to suggest that bookmark sync is working properly.

1. Re-enable Bookmark sync on your iOS devices.
2. And voila!

I’ve then taken this a step further. With the help of Xmarks my bookmarks are now in sync across all browsers, all computers and mobile devices I use at home and at work!

So with the New Year fast approaching I opted for a theme called iBizTech LightWeight created by the guys over at Technology Tricks. They’ve produced five versions in various colours but only this version has been updated to supports widgets.

I wasn’t a big fan of the light colour theme but noticed that the images for the other four colours were included in the download. So I decided to make a few modifications to suit my site.

1. Modified the CSS to use the orange skin
2. The CSS used for the sidebar didn’t play nice with Twitter Tools so made amendments to make the hyperlinks work properly
3. I didn’t really have the need for the ad banner so I replaced that with the social media icons
4. The featured post item was something I liked the idea of but it didn’t seem very flexible. I replaced the featured post code with the Dynamic Content Gallery plugin as this allowed for making a post “featured” whilst editing it.

I’ve got a few modifications to complete so the theme can be used as a proper child theme. Once completed I’ll look into making it available for download.

With that I’ll wish everyone a Happy New Year!!