UPDATE: Amazon just released a Domain Verification feature that can be used in combination with Verified Senders. Verifying a domain eliminates you from having to verify each email account you would like to send mail as. For more information, see their blog post.

To configure this service you first need an AWS (Amazon Web Services) account. If you do not have one, head over to Amazon to sign up. You will be required to enter your credit card information, but you will only be billed once you start using resources in the AWS cloud.

After your account is created follow these steps to configure SES (Simple Email Service). These instructions have been copied and condensed from Amazon's SES Getting Started Guide.

First, we need to create the AWS Access Keys (in this case, the SMTP username and password) that will allow your application or device to login to AWS.

To get your AWS access keys
1. Go to http://aws.amazon.com, click Account, and then click Security Credentials.
2. Navigate to the Access Credentials section of the page, and click the Access Keys tab.
3. Follow the on-screen instructions.

These next steps will walk you through verifying email addresses that are allowed to be impersonated by Amazon when sending emails. When you first sign up you are in a "sandbox" environment. While your SES account is in this state you will need to verify email addresses that you would like to send mail to until you are granted production access (please see the instructions later on in this post).

To verify your email address
1. Go to the AWS Management Console. Log in with the email address and password you used when
you signed up for Amazon SES.
2. In the Amazon SES console, click Verified Senders. If you are a new Amazon SES user, the list
should be empty.
3. To start the verification process, click Verify a New Sender.
4. In the Verify a New Sender dialog box, type your email address in the indicated field, and then click
Submit.
5. Sign in to your email client, and then find the message from Amazon SES asking you to confirm that
you are the owner of this email address.
6. To verify your email address, click the link in the email.

UPDATE: To verify your entire domain
See Amazon's guide at the following URL for setup instructions

http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/InitialSetup.DomainVerification.html

Once these instructions have been completed, you can begin testing. Just keep in mind the following restrictions (that are only in place until you are granted production access):

• You are only allowed to send to email addresses on the Verified Senders tab in the SES console.
• Only one message can be sent per second
• Only 200 messages can be sent within 24 hours

You can find your account's SMTP settings under the SES tab, then under the SMTP Settings link on the left navigation bar. Here you will find the SMTP server name, port numbers, and TLS settings for your outgoing SMTP server configuration. You will also need to specify the SMTP username and password that you were given when you created your access keys in the first set of instructions in this article. Go ahead and enter in all this information and try sending a test email from your application or device.

Once you confirm that you can receive mail at one of the addresses on the verified senders tab you can request production access here. This will remove all of the restrictions mentioned in the bulleted list above with the exception of requiring a verified sender to be specified. Production access will allow you to send email to any recipient without them being verified but you can only send "as" an address that has been confirmed and verified on this section of SES.

Please leave a comment with any questions or see the Amazon SES Getting Started Guide for more details.

Prerequisites and Assumptions

• All PCs using KMS licensing are running at least Windows Vista or Windows Server 2008 and newer. Windows XP/Server 2003 clients need additional configuration; I did not set this up in my case so I am unsure of the exact steps required.
• One available physical or virtual machine running either Windows 7 or Windows Server 2008 R2 to function as the KMS host (server).
  • Windows 7 KMS hosts can only activate Windows client operating systems. Windows Server hosts can activate both client and server products.
• A functioning DNS and AD server in your domain. If you do not run Active Directory, see this article for more information.
• For Office 2010 KMS activation see this site as it will not be covered here since the process is slightly different.
• All client PCs are able to communicate directly with the KMS server on a local area network (not over the internet as this is likely not supported by Microsoft for security reasons).
• You have an active Volume Licensing agreement with Microsoft and have Windows 7 or Server 2008 R2 KMS keys available.
• Make sure you install the proper key on the KMS host. The way the KMS key hierarchy works is slightly confusing; this TechNet article explains it best. Leave a comment if you are still unsure what key to choose. This hierarchy also includes information on activating earlier versions of Windows (Vista and 2008 R1).

Instructions

Note: These steps were referenced from this TechNet Article. They have been condensed and simplified for better readability and understanding. Please see the article for more information regarding steps that are unclear here.

Install the KMS host product key:

1. First, install the KMS key on the KMS Server by running the following from an elevated command prompt (right click Command Prompt and choose "Run as administrator"):
   slmgr.vbs /ipk <KMS Key>
2. After that completes successfully, run the following command to activate the key online with Microsoft:
   slmgr.vbs /ato
3. Alternatively, you can activate by phone using the following command in place of step 2:
   slui.exe 4
4. Restart the Software Protection Service by running the following:
   net stop sppsvc && net start sppsvc

Confirm that the KMS host has published itself in DNS:

1. KMS should create a PTR record in DNS automatically so clients know what server is hosting KMS activation on your network. To verify this open the DNS Management console on your DNS server.
2. Expand "server name" > Forward Lookup Zones > "Domain/Zone Name" > _tcp
3. If you see a record named "_VLMCS" with the KMS server name and port 1688 in the data field the record was successfully registered and you are done. If not, continue to the next step.
4. Right-click _tcp on the left had navigation bar, and choose "Other New Records".
5. Find and select "Service Location (SRV)" and click the Create Record button
6. Manually enter in "_VLMCS" (without quotes) in the Service field, "_TCP" (again, without quotes) in the Protocol field, 1688 in the Port number field, and the fully qualified domain name of the KMS server.
7. Click OK. KMS has not been configured and you are ready to start activating clients.

Now all that remains is to try activating a Windows client or server operating system with a KMS key. Remember, this will fail until at least 25 PCs have tried activating so don't worry if your first machines don't activate properly. The following error will be displayed if this is the case:

Error code 0xC004F038
The software Licensing Service reported that the computer could not be activated. The count reported by your Key Management Service (KMS) is insufficient. Please contact your system administrator.

I am not too certain why Microsoft puts in this requirement, but in reality it really isn't worth setting up KMS in an environment with fewer than 25 PCs so it should not be a problem. If you do not have enough new PCs to activate starting out you can always set up VAMT and convert the MAK/Retail keys of existing PCs to KMS to meet the quota. VAMT will allow you to do this remotely in batches to minimize the time required to convert existing activations.

VAMT can be downloaded from the Microsoft Download Center then see this article for more information about VAMT. See this article for any more questions relating to KMS activation, and this article for additional settings the KMS host can be configured to use. As always, leave a comment if there are any more questions or if there is something I missed.

Another bonus is that you can provision a dynamically expanding VHD so you only take up the space you need. For example, if you create a 120 GB dynamically allocated VHD and install Windows on it you will only consume around 8 - 10 GB (depending on OS) of space on the partition where the VHD is held. The VHD file will grow as additional room is needed, but the flexibility of not having to carve out a dedicated partition can be a big bonus. One drawback to keep in mind is the slight performance impact on the OS you are installing on the VHD, but in my instance this was not a problem.

I finally had a chance to give this feature a try when I decided to dual-boot my Windows 7 PC with Windows Server 2008 R2 running Hyper-V. A quick Google search turned up the this blog post.

Using the instructions in this post, I was able to successfully install and boot Windows Server 2008 R2 along with the Hyper-V role while minimizing disk space usage. The following steps are a condensed form of the instructions from Scott's blog post:

NOTE: These instructions will only work if you already have an existing Windows Vista or 7 installation. See Scott's blog for additional information if this does not fit your scenario.

1. Boot off of your Windows 7/2008 R2 disk.
2. Proceed with the installation as normal until you get to the screen with the "Install Now" Button. Click the "Repair your computer" link at the bottom of the install window.
3. De-select any Windows installations that are found (just click the white area below that entry) and click Next.
4. Select "Command Prompt".
5. Type "diskpart" (without quotes) and press Enter.
6. Enter in the following command, replacing the "file=" and "maximum=" parameters as needed. Maximum specifies the largest size the VHD can grow. Make sure you specify a directory that exists after "file=". This command will not create the directory along with the VHD file for you, it will only create the VHD.

   create vdisk file="C:\win7.vhd" type=expandable maximum=50000

7. Now that the VHD has been created, enter the following commands to mount it. Make sure you specify the same VHD and location that you entered in the previous step.

   select vdisk file="c:\win7\win7.vhd"
   attach vdisk

8.  Now type exit to quit disk part, close the command prompt, close the system repair window (click the "x" button, not reboot or shutdown), and proceed with the normal Windows installation. If everything went as expected you should see the VHD in the installation destination list. Choose that as you installation location and the rest is exactly the same as a normal Windows install.

The blog post from their website can be found here.

The parts list is as follows:

• Rosewill RSV-L4000 4U Rackmount Server Chassis with 8 3.5" Drive Bays
• SUPERMICRO MBD-X7SPE-HF-D525-O Server Motherboard
• Crucial 8GB (2 x 4GB) 204-Pin DDR3 SO-DIMM Memory
• PC Power and Cooling Silencer Mk II 500W High Performance Power Supply
• Verbatim Store 'n' Stay 4GB USB Flash Drive

The Supermicro motherboard was the most expensive component of the build since it is a server class board. In addition to the onboard USB port (which I will be using for the Verbatim 4GB flash drive for booting the FreeNAS install) this board supports IPMI for remote management of the system. This is essentially the same thing that Dell and HP servers allow you to do with DRAC and ILO. The board's specs also state that it only supports 4GB of memory, but upon additional research users have been reporting that it does in fact support 8GB, so I decided to give it a shot and order the above memory.

After I assembled all the components, I was able to successfully install FreeNAS to the USB flash drive via the IPMI console. It operated very much like a virtual machine, I mounted a local ISO and it mapped it over the network to the system. Very Convenient if you are often tinkering with your system and don't feel like hooking up a monitor and keyboard directly to the system.

After FreeNAS was installed, it did in fact recognize all 8GB and has been running without any issues for about a week. Right now I five disks in the system, four for my media volume (two 1.5 TB, and two 320 GB) and one for Time Machine backups. The four disk media volume is using two VDevs (two mirrored disks in each) which are members of the same ZPool for a combined total of 1.6 TB of storage. ZFS made it extremely easy to pool these differently sized disks into one large storage volume. Down the road I will be purchasing a few disks of the same model to add to this array as my storage needs grow.

Below is a picture of the FreeNAS System Information page, as well as the motherboard mounted in the case. All in all it was a great build and has been working perfectly. Considering the the hardware I have, I would say it definitively beats getting a dedicated appliance if you are not afraid of a little DIY.

More information:
FreeNAS Videos
FreeNAS Documentation

Prerequisites:
First, I am assuming you already have an AWS account and are somewhat familiar with the basics of AWS. Specifically working with security groups, starting and stopping instances, creating S3 buckets, etc....

Second, you need a virtual machine created in any VMware product, or VirtualPC/Hyper-V. VM Import also supports disk images in RAW format, but I am not aware of a free virtualization product that uses this yet.

Third, you need to download the Amazon EC2 API Tools and set your environment variables. For Windows, see this guide. When you get to the portion with certificates, make sure you are using the certs from the x.509 tab of your Security Credentials page.

"set EC2_PRIVATE_KEY" is for the .pem file prefixed with "pk-"
"set EC2_CERT" is for the .pem file prefixed with "cert-"

Alternatively, you can use the Amazon EC2 VM Import Connector for VMware vCenter if you are licensed for it and like to avoid the command line if possible.

Once you environment variables are set up, launch the batch file referenced in the earlier guide if you haven't already. Also make sure that you can run the "ec2-describe-regions" command without error. If all is good, you are finally able to start the actual import.

Import Virtual Machine Image Using the API Tools:

1.  Make sure you have a VMDK, RAW, or VHD disk ready. Please see this page for more details on what is supported.
2. Run the following command to prepare an Amazon Machine Image (AMI) and create a job id for the conversion:
   ec2-import-instance "<path-to-vm-image>" -t <instance type> -f <format> -a <architecture> -b <s3 bucket>
   -o <Access Key ID> -w <Secret Access Key>

   NOTE: The Access Keys can be retrieved from the security credentials page in your EC2 account. It is the same page where you retrieved the x.509 certs. Also take note that above command only uses the bare minimum options. Please see the API Tools Documentation for more details on what you can specify.

3. Run the following command to upload the image:

   ec2-upload-disk-image "<path-to-vm-image>" -t <Task ID> -o <Access Key ID> -w <Secret Access Key>
   NOTE: The Task ID will be output after you run the command in step two. Just search through the text it kicked back and you will find it. It is prefixed with  the word "import". API Tools documentation for this command can be found here.

4. Take a break. Step three takes a while since it has to upload the entire virtual disk. Don't worry if the transfer fails at any point, it will resume where it left off if it gets interrupted. After the upload completes you should see the following message:
   The disk image for <Task ID> has been uploaded to Amazon S3
   where it is being converted into an EC2 instance.  You may monitor the
   progress of this task by running ec2-describe-conversion-tasks.  When
   the task is completed, you may use ec2-delete-disk-image to remove the
   image from S3.

Go ahead and run the "ec2-describe-conversion-tasks" command to check in on the progress. I left mine run overnight, so I am not sure how long it took in my test. When it completes successfully, run the following command to delete the data stored in S3.

ec2-delete-disk-image -o <Access Key ID> -w <Secret Access Key> -t <Task ID>

Your VM is now imported into Amazon. Login to the AWS Management Console and start you instance. You can connect to it via RDP by using the Public DNS address listed on the bottom pane of the console when you have the imported VM selected. If it fails to connect, make sure you have RDP opened up in your security group.

You will undoubtedly run into issues the first time around while you are learning all the little tricks with the API Tools, but once you do it a couple times it gets to be very easy. It will be nice to see Amazon add some of these features to their web interface, but until then this is still a very easy and straight forward process. 

10 Scariest Hacks from Black Hat and Defcon

Many, if not all Samsung handsets use a proprietary file system for the phone's flash memory (which has been manufactured by Samsung as well) called RFS (Robust FAT File System). After researching this further, many people seem to be pointing fingers to RFS as the cause of many performance problems on Samsung devices.The solution comes in the form of a custom kernel that converts the RSF file system to EXT4.

After much trial and error getting it to flash properly due to the new EE4 update from Verizon blocking the GingerBreak exploit (used for rooting), I was able get full root and flash the new kernel with the instructions in this thread from XDA Developers. The only note that was missing from the instructions for installing CWM was that you cannot let the phone boot into the stock Samsung ROM after flashing CWM. This will remove it and require your to flash it again. Once you get the firmware flashed it will prevent the phone from reverting the recovery back to stock automatically.

[HOW-TO] Get a rooted version of EE4
http://forum.xda-developers.com/showthread.php?t=1122657

I used the PeanutButta Jelly Time firmware which includes the Voodoo lagfix. After that I used the GummyCharge ROM to replace the stock Samsung ROM. It is only running 2.2 at the moment, but I will likely start trying other ROMs down the road. This thread outlines what is currently available.

The following links are for the packages I used. Plug them in as needed when running through the instructions.

• Samsung Windows Drivers
• Odin (see thread, step 2 in the Preliminary steps)
• Clockwork Mod Recovery
• PeanutButta Jelly Time Kernel
• GummyCharge ROM. The original thread can be found here.
• I personally did not have trouble writing to the SD Card on the phone from Windows when I had it plugged in via USB. I was able to skip step 7 in the preliminary section. If not, proceed with patching as instructed.

SCVK - Realizing Your Opportunity in the Cloud