Samsung unveils Samsung Galaxy S III .. well ahead of the rumored iPhone 5 launch

Have you been caught in the rivalry between Apple and Samsung? It seems like a neck-to-neck battle between these two giants, with Apple backing its iOS device that revolutionised the mobile market some years ago, and Samsung pushing itself into the mobile market with Android (the mobile flagship OS of Google).

As most of you might be already aware, when the Samsung Galaxy SII came out, many took it to be the iPhone killer. With such close similarity to iPhone 4, it is no wonder why this phone has been so popular. Even so because it is so easy to use and with the loads of apps and hardware features it contains, it is a must have.

There are rumors that Apple is set to release its next iPhone in the coming months. This will surely be a must see product since it will be the first iPhone that would truely be released under the reins of Tim Cook. Will it have a bigger screen? NFC chip? Faster processor? A newer look?

Well ahead of the iPhone 5 launch, Samsung has unveiled its next installment in the Galaxy S series. The Samsung Galaxy SIII was unveiled in UK not too long ago. From first looks it seems like a marriage between Samsung Galaxy SII and Samsung Nexus. Unlike its predecessor, the new Galaxy SIII has got a more polished edge (like the Nexus). It boasts a quad core processor and has got Android 4.0 installed (Ice Cream Sandwich).

Currently the Samsung Galaxy SIII has only been announced for UK and Europe markets but the company has announced that other countries will soon follow.

Will you be rushing out to buy this new phone? Or will you wait till the next iPhone is released to decide which one to get?

You can read more about Samsung Galaxy SIII at the following websites

Tech Jungle
Sydney Morning Herald
Engadget

Get-PublicFolderStatistics - Couldn't find public folder on server

Using the Exchange Management Shell in Exchange 2010, if you try to get the statistics of a Public Folder PFolder on server ExchangeServer01 using the cmdlet Get-PublicFolderStatistics, you might get an error like the following

Get-PublicFolderStatistics PFolder -server ExchangeServer01

Couldn't find public folder {PFolder} on server {ExchangeServer01}

+ CategoryInfo          : InvalidData: (PFolder :PublicFolderIdParameter) [Get-PublicFolderStatistics], InvalidOperationException
+ FullyQualifiedErrorId : 785BD1AB,Microsoft.Exchange.Management.MapiTasks.GetPublicFolderStatistics

This seems to be a bug since the PublicFolder "PFolder" does exist!

A workaround for this is to add the parameters -ResultSize unlimited to the cmdlet. So modifying the above example with the new parameters,

Get-PublicFolderStatistics PFolder -server ExchangeServer01 -ResultSize unlimited

gives the correct results.

I hope this helps people since it surely had me baffled for a while.

The above is from http://mykbit.blogspot.com.au/2011/05/couldn-find-public-folderwhen-get.html

ec2-107-21-251-69.compute-1.amazonaws.com what is this?

I had a user come up to me this week with a very weird issue. They had a jailbroken iphone and ever since a few weeks ago, it had been freezing on him. Well my first reply was, thats what you get when you jailbreak an iPhone ;) Actually jailbreaking an iPhone gives you a lot of freedom to do things on it.

Anyways, I looked through the phone and did not find anything odd on it. I then enabled a ssh server on it and connected. I decided to check if the phone was doing any weird tcp connections.

Doing a netstat revealed all. In between the "normal" traffic was one that I had not seen before. ec2-107-21-251-69.compute-1.amazonaws.com
It seemed that connection to this destination was always kept alive. Since the version of netstat on the iPhone does not have options to reveal the PID of the offending process, I was at a loss.

I googled the above address and managed to find some articles that linked it to Viber (this is like Skype). Since SBSetting was already installed on the iPhone, I looked through the currently running processes and found Viber listed. I killed it, and presto! The connection to ec2-107-21-251-69.compute-1.amazonaws.com was no more!

The iPhone was still slow so in the end, the best solution was to install the legit iOS on it :(

The cluster service has determined that this node does not have the latest copy of cluster configuration data

A few days ago I got a big surprise on my Exchange 2010 Servers. While doing a routine daily check via Exchange Management Console, I noticed that one of my DAG servers was reporting its status as Failed. This looked really weird since the server itself was online and I could ping it.

I RDP'd to the problematic server and checked the eventlogs. To my dismay, I found that the following was being logged in the system logs

Event ID 1564 - File share witness resource 'File Share Witness (\\Server1.domain.com\DAG.domain.com)' failed to arbitrate for the file share '\\Server1.domain.com\DAG.domain.com'. Please ensure that file share '\\Server1.domain.com\DAG.domain.com' exists and is accessible by the cluster.

I opened the Failover Cluster Manager and found that the above server had been marked as down. This explained why the server was being reported with a status of Failed in the Exchange Management Console.

I checked the permissions on the DAG share above. The NTFS permissions looked alright. However, the share permissions had an unresolved SID. I took this to be the culprint and doing a bit of googling I found that the cluster computer account should be listed in the share permissions with Full Control. Since this was not listed, I took the liberty of adding in DAG$ in the share permissions with Full Control (my DAG name is called DAG .. yea yea very original).

After doing the above, I noticed that the above error was no longer being shown,  but instead the following error appeared.
"Event ID 1561 The cluster service has determined that this node does not have the latest copy of cluster configuration data."

And to add salt to my injury,  the server was still marked as down in Failover Cluster Manager. I googled the error and managed to find some articles on it. One of the support articles from Microsoft said to start all the other nodes and if they started, then the affected node will read the configuration off them and start. However, since I already had a node running (the other DAG server), this didnt quite apply.

I tried restarting the cluster services on the affected server, but even this did not resolve the issue. Restarting the server was no help either.

Finally, with a stroke of genius (and luck), I decided to restart the cluster. So from the Failover Cluster Manager,  I right clicked on the cluster name (which quite originally was called dag.domain.com) and then under More Actions  I selected Shut down Cluster. A prompt came up asking if I really wanted to shut down the cluster. I chose Yes.

After a few minutes (well actually 2min), with fingers crossed, I started the cluster (from Failover Cluster Manager, right click on the DAG name and from More Actions select Start Cluster). Viola, both the DAG servers came back online!

I quickly checked Exchange Management Console and saw that both the servers were now being reported as online. The problematic server was now being updated from the other server (you might see a huge CPU spike on the problematic server while the updates are copied to it)

Take care and until the next time. And remember, with windows, you restart :)