Pages

Saturday, December 22, 2012

Hyper-V Replica Short Review


I've been using Server 2012 for sometime now, but I've just recently setup Hyper-V on a few of those systems. I think over all Hyper-V's offering really hasn't changed much, but the addition of Replica certainly is a big one. I think it's a great, low-cost solution for disaster recovery. I do not, however, think it should be considered an all-in-one solution. Using just the Server 2012 built-in solutions such as the built-in backup, used along with Hyper-V Replica it gets closer, but still not there. My opinion is VMware is still ahead of Microsoft by far. The gap is closing; especially in the SMB market, which Microsoft intends to keep, and VMware hopes to penetrate. I think it is worth knowing about and fully understanding uses for Hyper-V in place of VMware, but I will say in the small to medium deployments, I don't think I'd use Hyper-V or Hyper-V Replica for DR.

The truth of the matter is Microsoft and VMware both offer a reliable Hypervisor. Just for the balloon driver alone, my preference will always be VMware. On the other hand, Microsoft's answer to ballooning is more physical ram. Hyper-V does have Dynamic Memory (DM), which is new, and while it is nice it is not perfect. This plays a big part in deployments that need to scale. I also do not fully appreciate Microsoft's built in backup. There are many things that Microsoft does well, but backups have never really been one of them. In Server 2012 that seems to still be true, and that plays a big part in designing DR. In practical use more times than not someone needs a new VM right away. If you are using Microsoft Hyper-V and do not have the extra memory available, you will have to get that memory before you can deploy a new VM. In the same scenario using VMware vSphere, you can deploy the VM and order the additional memory at your leisure, if it is even required.

Because of the differences in how Hyper-V and ESXi allocates and manages memory, I think VMware makes a far better Hypervisor for disaster recovery. Suppose your company doesn't have a DR site, or even extra servers to be DR systems! While Microsoft certainly supports far more white box systems than VMware, you can far over commit a ESXi host, whereas a Hyper-V host not so much. Without upsetting those pro Hyper-V it all comes down to what you prefer and how you plan. I certainly wouldn't forgo deploying or supporting Hyper-V, it's just not my preference. In most cases your environment was inherited. As with all networks, it is comprised of systems and software the previous or lead admin selected. Ergo, you're stuck with what you have. Those who are lucky enough to be revamping or building a network from the ground up choose wisely. If you're using Microsoft for virtualization there is no doubt that your DR strategy would be different than it would be when using VMware.

That being said, I found a blog here, that I think covers Hyper-V Replica extremely will. His expertise on the topic far exceeds my own, which is why rather than trying to cover Hyper-V Replica I will simply link to him. I think it's worth others taking a look regardless if you're already using Microsoft or VMware for virtualization. Additionally on the right hand side of my blog, under the diagram section, you can find a link to the Microsoft Hyper-V Replica Companion Reference, as well as here.


Wednesday, December 19, 2012

Significant increase in the spread of W32.Changeup worm

I've run into a number of worms over the years but typically I see them in a network or two here and there. I've run into W32.Changeup several times in the past few days and I expect to see it a few more. It can get into your network via removable media or the Internet. From the infected computers it will replicate to net shares, and infect new computers that go into those shares via autorun. It will replicate to any net share that it can get into if the user has write permissions or via system account impersonation. It will also replicate to sysvol on domain controllers which is why it can spread so fast. It will also replicate to unprotected shares on Mac and Linux systems, but will only infect Windows PCs. To stop further infections disabling autorun across your domain or on your PC will be required. If you need help disabling autorun you can find instructions here.

If autorun is disabled all you really need to do is isolate the infected machines and re-image them offline. Assuming you have virus protection scanning your network the files it leaves behind should be cleaned up automatically and will not come back unless you still have infected machines. Once the infections are contained and eliminated you will need to fix the net shares the worm changed. You will likely start receiving calls from users saying their mapped drives are empty, and you likely will not be able to find them on the server. The worm marks all files and folders in net shares it replicates to along with the root folder as hidden system files and folders. In order to fix it you must remove the attributes via command prompt. I've successfully resolved the issue by logging into each file server as a domain admin, unhide protected operating system files, take ownership of the root shared folder, adding the domain admin account as full control, forcing the permissions down, and the running the below commands.

Removes attributes from root shared folder
Attrib -H -S C:\path\to\your\folder /S /D

Removes attributes from subfolders and files
Attrib -H -S "C:\path\to\your\folder\*.*" /S /D

Once the above is done you may still find random movie files or links in various folders that are 0 to 1 KB in size. You should perform a search for files that are the size of 1 KB or less and confirm or deny if they were there before the infection using backups. If they weren't delete them so that users do not mistakenly open them. The links will vary in name but the movie files seem to be named a single letter like x.mov and the size 0 to 1 KB. The very last step will be to correct the permissions you reset back to what they were pre-infection if the entire share tree did not have the same permissions.

CRM News W32.Changeup
Symantec's Security Response to W32.Changeup
Reset system and hidden attributes caused by W32.Changeup

Tuesday, December 4, 2012

Installing Cacti in Debian 6

Recently I needed to monitor a network segment of a client's network. They were relatively small but were having over utilization issues. Using Cacti, which is a free Linux based SNMP monitoring/graphing program I was able to track network performance metrics such as bandwidth and throughput of switches and firewalls. When used in conjunction with vCenter performance graphing it shouldn't take long to pinpoint issues you are experiencing. This tool requires SNMP to be configured per device and then pointed at the Cacti server to start tracking and logging the various metrics. Below is a quick tutorial for setting up a Cacti server.

Note: You will not need to download Cacti separately or in advance but for the purpose of learning more about Cacti below is the link the developer’s website.

http://www.cacti.net

Hardware specs used
To install Cacti you will need either a physical computer or a VM. We will be installing our Cacti server into a VMware VM. For the Debian install I created a VM with 2 sockets and 1 core, 1 GB of memory, and a 40 GB hard drive.

Installing Debian 6.0.6
The link to the Debian download can be found below. You will need the Debian amd64 ISO. When you select the download ignore the reference to "amd", it is what Debian calls their general 64 bit OS release. As of 11/27 the name of the latest DVD you need is debian-6.0.6-amd64-DVD-1.iso. Install Debian like you would any operating system with the only exception being enable network mirrors during the installation. Shortly after partitioning the disk you will be asked if you want to use a network mirror for additional repositories. Ensure you select use a network mirror during the install, and point it to one of the many Debian depositories available in the list provided. I selected the first in the list. Failing to do this step will prevent you from installing Cacti the easy way later on. The last step of setting up your Debian VM is to setup a static IP and then you are ready to move on.
 
Debian 6.0.6 amd64
 
Installing VMware tools
Once you get to the desktop you need to install a few Linux components that are not installed by default and then the VMware tools for Linux. You can find the link to install the Linux components and VMware Tools for Linux on Debian HERE.

Installing Cacti
For the Cacti install if you added the network repositories as recommended you will simply need to open one last root terminal and run the command apt-get install cacti and hit enter. You will be prompted to create a MySQL password, and when asked what web server you should use select Apache2. Follow the remaining prompts and supply the required passwords you used to setup the OS and the installation of Cacti should complete shortly. Once the Cacti install finishes, open a web browser, and point it to http://IP ADDRESS/cacti/. You will be asked a few basic questions, which is again as simple as next, next, and next. If all went as according to plan, you should now be seeing a login screen. The default login is admin for the username, and admin for the password. Upon first login you will be required to change your password. You are now ready to add SNMP devices and servers to be monitored, and graphed.

Saturday, December 1, 2012

How to confirm domain user SIDs and SMTP addresses


I was recently managing an Exchange migration for a company and had an interesting problem. On the surface it appeared I was over the hump and close to completion so everything seemed spot on. However, on the home stretch I started seeing applications issues. I chalked it up to a specific VM having a problem but then the issues started following me to another Exchange VM. I managed to resolve the issues and then simply moved on. Later on upon attempting to remove the legacy Exchange via Add/Remove programs the uninstall failed. I almost went the route of manually removing the Exchange server from Active Directory with ADSI edit when I noticed the X400 address for the domain administrator ended with a 2.

After much digging I was left puzzled, and with a much larger question. The previous IT didn't leave any real documentation, and management had no idea if the admin account was renamed. Luckily I found a VB script to run which reports all of the SIDs in the domain and then dumps it into Excel. I also used a second VB script to list all of the email addresses within the domain which led me to find a restricted user account with an smtp proxy address of administrator2@domain.com. Other than that small detail and the X400 address on the currently named administrator account I had no way of knowing which was which. Additionally the renamed account was on a list of users which I was given to remove after the migration was complete. Both accounts will need to be kept now because one is the default S-500 account, and the other was used to install the new version of Exchange.

The scripts worked perfectly to identify the S-500 default domain account, and to identify the account that was currently named Administrator was a fake. When I started the project I was given the account and told it had all of the permissions needed. Confirming the S-500 account will now be a standard practice of mine going forward. You can find the links to the VB scripts I used below. Simply save the files and rename the extension to ".VBS".

List SIDs script

The machine you run the List SIDs script on must have Excel installed as the script will dump the output directly into Excel. When you run the VB script it will ask you to enter the name of the server OR workstation you are running it from. You do not need to be logged into the workstation as a domain admin to run it because all users and computers joined to the domain have full read access to Active Directory.


List SMTP addresses script

The machine you run the SMTP script on should be a domain controller or Exchange server. To run the script on Server 2003 simply double click the file and it will dump the output to a text file in the root of C:\ called emailaddresses.txt. To run the script on Server 2008 or later you must run it from an administrative command prompt. Again, it will dump the output to a text file in the root of C:\ called emailaddresses.txt.