AWS EBS Volume Encryption Feature Now Available

According to Amazon Web Services they have announced encryption support for EBS volumes. EBS encryption will enable users to meet strict security and encryption compliance requirements and at no additional cost.

You can now create an encrypted EBS volume and attach it to a supported instance type. Data on the volume, disk I/O, and snapshots created from the volume are all encrypted.

The encryption occurs on the servers that host the EC2 instances, providing encryption of data as it moves between EC2 instances and EBS storage.

You can use and manage encrypted EBS volumes and snapshots via the AWS Management Console, Command Line Interfaces (CLIs), Amazon SDKs, or the Amazon EC2 API directly

To create an encrypted EBS Volume Via the AWS Management Console,

1 - Log on to the AWS EC2 Management Console, Under Elastic Block Store, Click Volumes
2 - Click the Create Volumes button, Fill and choose the options as necessary and select the encryption check box (remember to create the volume in the same AZ as the instance yo want to attach it to)

Please Note: you cannot enable encryption for an existing EBS volume. Instead, you must create a new, encrypted volume and copy the data from the old one to the new one using the file manipulation tool of your choice, i.e. Rsync on Linux and Robocopy on Windows.
For More Information: Amazon EBS encryption now available

Problem with WinRM on Exchange 2013 Management Shell and Exchange Toolbox on a new exchange 2013 with CAFE and BE on single server installation

While deploying MS Exchange 2013 I experienced issues with accessing the Exchange Management Shell and Exchange Toolbox. Whenever I tried to open the Exchange Management Shell I kept get the following error:


VERBOSE: Connecting to Exchange2013.DOMAIN.LOCAL
New-PSSession : [exchange2013.domain.local] Connecting to remote server exchange2013.domain.local failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (exchange2013.domain.local) returned an 'access denied' error. Change the configuration to allow Kerberos authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.

VERBOSE: Connecting to EXCHANGE2013.LOCAL.COM.
New-PSSession : [exchange2013.domain.local:80] Connecting to remote server exchange-bt.tmal.com failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (exchange2013.local.COM:80) returned an 'access denied' error. Change the configuration to allow Kerberos authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.

Workaround and Resolution:

Searching the error on Google and all over the web resulted in various and numerous solutions most that worked for there environment but failed to address my issue, but made me realize that this was a Powershell website issue.
Exchange 2013 installs a Default Website (Client Access front End) on port 80 and 443 and also a Backend Website on port 81 and 444.

Here is how i managed to sort out my issue, I had to Change the physical path from: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell to: C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell and then issued an IISRESET.

This is how I went about diagnosing this, with the first Exchange Server 2013 installed and running, I installed a second Exchange 2013 Server with only the Mailbox server role.
On the second Exchange Mailbox server I was able to access the EMS and the Exchange Toolbox successfully.
Now from here on it's simple I only have to do a comparison of the Powershell settings in IIS Manager on these two Exchange servers.

Internet Information Services (IIS) Manager, Sites, Default Web Site, PowerShell and in the Actions Pane, choose Basic setting, physical Paths - on exchSvr1 has C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell while exchSvr2 has C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell on exchSvr1 changed the physical path to C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell

After changing all these i did an iisrest on the exchSvr1 (the affected server) and tried the EMS and Exchange Toolbox, they all worked.

Gateway Load Balancing and Router Redundancy with HSRP & GBLP

I have two ISP's providing VPN links between my HQ and three remote offices, we are using broadband links and Leased Lines in all the sites, the idea for this is to provide route redundancy/failover in case one router fails.

I did some research on how best to achieve this, and two Cisco technologies were highly recommended for this; Gateway Load Balancing Protocol (GLBP) and Hot Standby Router Protocol (HSRP).

GLBP is cisco's newest Gateway redundancy feature and it operates @ layer 2. It elects one of the members of the GLBP Virtual Gateway, and this acts as the ARP responder.

HSRP is a cisco proprietary redundancy protocol for establishing a fault-tolerant default Gateway. The protocol establishes a framework between network routers in order to achieve default gateway failover. If the primary gateway should become inaccessible, in close association with a rapid-converging routing protocol like BGP, EIGRP or OSPF.

more reading : Redundant Protocols - GBLP, HSRP , HSRP vs BGLP vs VRRP , How to Configure HRSP for Load Balancing

Of the two protocols, I had to settle for HSRP as I only have a few client computers in remote sites that one link could easily handle so load balance is not necessary.

Sample Config for Site A

Router A

int FastEthernet0/0
ip address 1.0.0.1 255.0.0.0
standby 1 preempt
standby 1 ip 1.0.0.3
standby 1 priority 110

Router B

int FastEthernet0/1
ip address 1.0.0.2
standby 1 preempt
standby 1 ip 1.0.0.3



Router B - f0 = 7

Cacti not producing graphs or creating rrd

yesterday i was installing cacti on my debian 4.0 box, which i normally use for monitoring my network, after the installation and configurations, i realised that cacti was not plotting the graphs for the devices I had added, even status was showing Unknown on all devices.

I checked both snmp and rrdtool, but both were running smoothly, this was a bit strange as even the /usr/share/cacti/site/rra folder was blank, cat /var/log/apache2/error.log resulted in:

localhost_server_traffic_in_18.rrd': No such file or directory ERROR: opening '/usr/share/cacti/site/rra
etc etc.
running the php poller file manually from the shell came back with: Fatal error: Call to undefined function: mysql_pconnect() in /usr/share/php/adodb/drivers/adodb-mysql.inc.php on line 377.

This was really interesting as i am having phpmyadmin running smmothly without problems, so why does my php seem to break in cacti, on the cacti forum somebody pointed that cacti package depends on php5-cli, i checked and realised i was having php4-cli on my box, apt-get install php5-cli sorted out this, and i have my graphs in Cacti

Error message when you try to log on to a Windows Server 2000 - based terminal server

Last week, I installed and run spybot on a Windows 2000 terminal server, and also some windows updates (NB; For some reason or another, but not known to me, this server has never had any windows and antivirus updates for some time, and it was showing signs of infections), after a restart over the weekend due to the updates, Users this morning started reporting failure to log on to the terminal server with this error:

"Windows cannot log you because the profile cannot be loaded. Please contact your network Administrator (in this case me), insuficiet system resources exists to complete the requested service"

Now, I half expected this or atleast some problems to surface after the maintenance work I did on the server.

However, it did take me a good 30 minutes to sort this one out, microsoft knowledge base, suggested two things, first increasing the maximum registry value (Control Panel -> system -> advanced -> perfomance options -> Change

Secondly tweaking the registry.

1. click start -> run -> type regedit and hit Enter.
2. Locate and click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
3. On the Edit menu, point to New and then click DWORD value
4. In the New Value #1 box, type PoolUsageMaximum, and then pres ENTER.
5. Right-click PoolUsageMaximum, and then click Modify
   
6. In the value data box, type 60, click Decimal, and then click ok
7. if the PagedPoolSize registry entry exists, go to step 8. If the PagePoolSize registry entry does not exist, create it. ( Edit Menu -> New -> DWORD Value -> type PagedPoolSize in the New Value #1 box, and press Enter.)
8. Right-click PagedPoolSize, and thn click OK
9. Exit Registry Editor, and then restart the computer.

Everybody, is working fine now and the phones have gone queit

Trouble Shooting WSUS problems - Clients not populating in WSUS Admin Console

I have had to install WSUS twice on my server due to conflicts with SEPM, the first install WSUS was configured to use Port 80, and I used the Default Domain Policy to direct Client Computers to it.

when i was reinstalling the WSUS to use port 8530, i created a policy called WSUS on the DC, that would control clients automatic Update configuration. unforunately only 4 out of over 120 PC's only reported to the WSUS.

Doing Start ->Run, then rsop.msc on one of the failing machines showed Group Policy was not being applied correctly, i realised that the Default domain Policy was still having the old settings of my first WSUS configuration i.e. the intranet update server was showing http://servename instead of http://servername:8530.

Cleaning out the Default Domain Policy of all windows Updates setting and allowing the WSUS policy that had the right settings did the trick, all my computers populated and reported to the WSUS Console within hours.

Setting Up a WSUS Server along with SEPM

Recently i installed WSUS on a server running Symantec endpoint protection Manager using default settings, and i didn't know that this is not recommended until my SEPM stopped working correctly..

The problem is both WSUS and SEPM create a virtual directory in IIS called content, and whichever was installed first will stop working, normally it's recommended to install WSUS on Port 8530 on a server where sharepoint or SEPM is already installed.

So basically I had to unistall the WSUS, sort out my SEPM, and re-installed my WSUS to use port 8530 and it's own virtual content directory and update the group policy to point to http://servername:8530.

After this I had WSUS and SEPM working in harmony.