Citrix XenApp

Your Journey towards cloud.

Virtualization Picking up Speed

Are your Skills keeping up? Skill up. Be Relevant

Are you a System Admin

Learn Citrix XenApp, Its future.

Citrix XenApp

Industry-leading virtualization platform for building cloud.

Cloud Computing in Demand

Learn how to build cloud on Citrix XenApp.

Monday, 27 June 2011

Error during upgrade: The system call API checksum doesn’t match

Today, I got an error during upgrade from vSphere 4.0 to 4.1 stating something like:

The system call API checksum doesn’t match

There was a lot of similar lines filling the console. I was a bit worried that the upgrade had gone wrong even though I had done three similar upgrades before this one with no errors - and that I would have to reinstall in stead.

Luckily, I found this error description in the 4.1 release notes stating that a reboot will fix the issue. So I waited for a while to be sure that the upgrade finished, rebooted, and everything looks fine:

Link to release notes:

"ESX service console displays error messages when upgrading from ESX 4.0 or ESX 4.1 to ESX 4.1 Update 1
When you upgrade from ESX 4.0 or ESX 4.1 release to ESX 4.1 Update 1, the service console might display error messages similar to the following:
On the ESX 4.0 host: Error during version check: The system call API checksum doesn’t match"
On the ESX 4.1 host: Vmkctl & VMkernel Mismatch,Signature mismatch between Vmkctl & Vmkernel

You can ignore the messages.

Workaround: Reboot the ESX 4.1 Update 1 host. "

Wednesday, 1 June 2011

Add open cmd prompt here to context menus


Copy following to notepad and save as cmd here.reg



Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Drive\shell\cmd]
@="Command Prompt"

[HKEY_CLASSES_ROOT\Drive\shell\cmd\command]
@="cmd.exe /k \"cd %L\""

[HKEY_CLASSES_ROOT\Directory\shell\cmd]
@="Command Prompt"

[HKEY_CLASSES_ROOT\Directory\shell\cmd\command]
@="cmd.exe /k \"cd %L\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell\cmd]
@="Command Prompt"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell\cmd\command]
@="cmd.exe /k \"cd %L\""

Sunday, 1 May 2011

Computer Matinence

You may not realize it, but your computer and your car have something in common: they both need regular maintenance. No, you don't need to change your computer's oil. But you should be updating your software, keeping your antivirus subscription up to date, and checking for spyware. Read on to learn what you can do to help improve your computer's security.


Getting started

Here are some basics maintenance tasks you can do today to start improving your computer's security. Be sure you make these part of your ongoing maintenance as well.

* Sign up for software update e-mail notices. Many software companies will send you e-mail whenever a software update is available. This is particularly important for your operating system (e.g., Microsoft VV!|VD0VV$® or Macintosh), your antivirus program, and your firewall.
* Register your software. If you still have registration forms for existing software, send them in. And be sure to register new software in the future. This is another way for the software manufacturer to alert you when new updates are available.
* Install software updates immediately.
When you get an update notice, download the update immediately and install it. (Remember, downloading and installing are two separate tasks.)
An ounce of prevention

A few simple steps will help you keep your files safe and clean.

* Step 1: Update your software
* Step 2: Backup your files
* Step 3: Use antivirus software and keep it updated
* Step 4: Change your passwords


Developing ongoing maintenance practices

Now that you've done some ground work, it's time to start moving into longer term maintenance tasks. These are all tasks that you should do today (or as soon as possible) to get started. But for best results, make these a part of a regular maintenance schedule. We recommend setting aside time each week to help keep your computer secure.

* Back up your files. Backing up your files simply means creating a copy of your computer files that you can use in the event the originals are lost. (Accidents can happen.) To learn more read our tips for backing up information.


* Scan your files with up to date antivirus software. Use your antivirus scan tool regularly to search for potential computer viruses and worms. Also, check your antivirus program's user manual to see if you can schedule an automatic scan of your computer. To learn more, read our tips for reducing your virus risk
.
* Change your passwords. Using the same password increases the odds that someone else will discover it. Change all of your passwords regularly (we recommend monthly) to reduce your risk. Also, choose your passwords carefully. To learn more, read our tips for creating stronger passwords
.

Making a schedule

One of the best ways to help protect your computer is to perform maintenance regularly. To help you keep track, we suggest making a regular "appointment" with your computer. Treat it like you would any other appointment. Record it in your datebook or online calendar, and if you cannot make it, reschedule. Remember, you are not only helping to improve your computer, you are also helping to protect your personal information.

Sunday, 17 April 2011

Installing View 4.6 in home lab

In this post I will not go into detailed installation steps, in stead I'll try and give an overview of the components that I have used (local mode and linked clones not included) and then link to the posts I've used for inspiration.

Components

First of all, a vCenter installation and a domain controller are required. I have chosen to go with Windows Server 2008 R2 but other than that it is pretty much standard installations.

The main component of the View installation is the Connection Server. And then there is the Security Server which is basically a subset of features from the Connection Server. After installation it is linked to the Connection Server from the Connection Server administrative web interface - and it is also configured from there.

I used this excellent guide by Poul Slager to install the Connection Server. I did the same as Poul and installed just one Win7 VM with the View agent on it and added it to a static pool.

A new feature in View 4.6 is that the PCoIP protocol can now be used also from external sources (e.g. from outside the company network) but this requires a Security Server. The Security Server is typically placed in a DMZ and it is the Security Server which establishes the PCoIP connection directly to virtual desktop.

At the VMware View blog, there's a post with a 40 minute video explaining the infrastructure and new features of View 4.6.

For the specific configurations for enabling PCoIP from external sources, I used the Setting up PCoIP Remote Access with View 4.6 document.

I experienced a strange error when at first I connected to the Security Server from and external source. It worked fine internally but from the outside I could connect and authenticate but then the remote connection just showed a black screen for about 10 seconds and the connection closed. In the View desktop event viewer there was en entry stating: "Closed PCoIP connection doesn't match global value". To fix this I adjusted the configuration in the Connection Server under View Configuration -> Servers and made sure that the external URLs for the Security Server and the Connection Server were identical. The external URL was set for the actual outside URL in both cases and the IP was set for the outside ip of the ADSL modem in both cases - this solved the issue in my case (see screen dumps below).

Currently, with all the components running, the setup is taking up about 10 GB of memory, so there's still room to load up the ESXi box, it has a total of 16 GB, with more VMs! (see screendump below).





Networking

For routing and firewall internally between the infrastructure components I chose a Vyatta virtual appliance which I downloaded from VMware Marketplace. Per default, this appliance included three NICs which suited my requirements for creating an inside LAN, outside LAN, and a DMZ for the security server. On the vSwitch I have created three different VM networks. However, I have not VLAN tagged any of the networks as only one ip range will leave the physical ports on the switch (the Vyatta router acts as gateway for all the infrastructure components).

The learning curve for the Vyatta is quite steep in my opnion. I have spend my fair share of hours trying to figure out the logic of the NAT, DNAT, and the firewal rules. For configuration I have been using a mix between the web gui and the CLI. The CLI is actually quite nice when you get used to it (TAB is your friend).
Remember to save your configurations to disk before rebooting or you will loose all configurations (I learned this a couple of times ;-)). So obviously type 'configure' to into configuration mode and then 'commit' when your done. 'Exit' to exit configuration mode. 'save config.boot' to save configuration to disk. Default credentials for the vyatta is user: vyatta, pw: vyatta.

To get started and setup the Vyatta I used the Quick Start Guide which you can get at vyatta.org. At the site there is also a quick start video which is useful.

And then for firewall configuration etc. I used this guide which worked surprisingly well.

The basic principle for the router in this setup is that you want to allow all traffic from the Inside Lan and the DMZ to be able to get out to the internet. You also want your Inside LAN to be able to access the DMZ. All traffic from the Outside entering the gateway NIC on the router should be dropped. However from all addresses on the Internet, access on port 4172 should be allowed (and directed) only to the security server. And then only the Security server's IP will be allowed to open connections on the same port to the inside LAN. So for 'opening up' a port in the firewall you will need both a firewall rule and a DNAT rule (destination NAT). This last part had me quite confused.

So, the final setup currently configured according to the diagram below. I used it to connect to the View Desktop and from there I can open a vSphere client and have full access to the vSphere home lab.

Friday, 1 April 2011

Delete An Undeletable File

Open a Command Prompt window and leave it open.
Close all open programs.
Click Start, Run and enter TASKMGR.EXE
Go to the Processes tab and End Process on Explorer.exe.
Leave Task Manager open.
Go back to the Command Prompt window and change to the directory the AVI (or other undeletable file) is located in.
At the command prompt type DEL <filename> where <filename> is the file you wish to delete.
Go back to Task Manager, click File, New Task and enter EXPLORER.EXE to restart the GUI shell.
Close Task Manager.


Or you can try this

Open Notepad.exe

Click File>Save As..>

locate the folder where ur undeletable file is

Choose 'All files' from the file type box

click once on the file u wanna delete so its name appears in the 'filename' box

put a " at the start and end of the filename
(the filename should have the extension of the undeletable file so it will overwrite it)

click save,

It should ask u to overwrite the existing file, choose yes and u can delete it as normal


Here's a manual way of doing it. I'll take this off once you put into your first post zain.

1. Start
2. Run
3. Type: command
4. To move into a directory type: cd c:\*** (The stars stand for your folder)
5. If you cannot access the folder because it has spaces for example Program Files or Kazaa Lite folder you have to do the following. instead of typing in the full folder name only take the first 6 letters then put a ~ and then 1 without spaces. Example: cd c:\progra~1\kazaal~1
6. Once your in the folder the non-deletable file it in type in dir - a list will come up with everything inside.
7. Now to delete the file type in del ***.bmp, txt, jpg, avi, etc... And if the file name has spaces you would use the special 1st 6 letters followed by a ~ and a 1 rule. Example: if your file name was bad file.bmp you would type once in the specific folder thorugh command, del badfil~1.bmp and your file should be gone. Make sure to type in the correct extension.

Thursday, 31 March 2011

Installing Windows Remote Management (WinRM) and PowerShell 2.0 on Windows Server 2003 / XP

Windows Remote Management WinRM and PowerShell 2.0 are two very versatile tools that can greatly increase the manageability of your Windows hosts.  Unfortunately it has been somewhat difficult for me locating the most up to date versions of this software.  Basically the package available that installs PowerShell 2.0 also includes the WinRM 2.0 release as well.  Also available at the link below are WinRM/PowerShell 2.0 releases for Windows Vista and Server 2008 R1.
There is a prerequisite that the computer is running Microsoft .Net Framework 2.0 SP1.  I have included a link below to .Net 2.0 SP2:
Now you can install the WinRM 2.0/PowerShell 2.0 Management Framework package here:

Friday, 25 March 2011

Install Samba Server on Red Hat Enterprise Linux/CentOS/Scientific Linux 6

Recently the latest version of Scientific Linux 6 was released. Scientific Linux is a distribution which uses Red Hat Enterprise Linux as its upstream and aims to be compatible with binaries compiled for Red Hat Enterprise. I am really impressed with the quality of this distro and the timeliness with which updates and security fixes are distributed. Thanks to all the developers and testers on the Scientific Linux team!
In this post I will discuss installing Red Hat Enterprise Linux/CentOS/Scientific Linux 6 as a Samba server. The instructions should also be relevant to other Linux distros including CentOS. This example will rely on a local user database as the mechanism to provide security. In future posts I may discuss more complex scenarios including integrating the Samba server into Windows domains and Active Directory.
Let’s start off by installing the Samba server package and its dependencies:
# yum -y install samba
It is a good idea to set up a distinct group to allow access to the directory we will share. I will specify a group ID to prevent any overlap with the default groups created when individual users are added, which on most Linux distros these days start at 500 or 1000.
# groupadd -g 10000 fileshare
Now we will create a directory that will host our Samba share:
# mkdir /home/data
We need to modify the permissions on the directory to allow write access for users in our new group:
# chgrp fileshare /home/data
# chmod g+w /home/data
SELinux
UPDATE (5/10/2011): Recently I was setting up a Samba share on an existing file system that already contained files and I was unable to get SELinux configured to allow Samba to function correctly. This occurred even with using the -R option specified below to re-curse and relabel the existing files. So be aware that you may have problems like I did and you may need to set SELinux to permissive or disabled in the “/etc/selinux/config” file. In my case there were no denials logged in the “/var/log/audit/audit.log” so it was very difficult to troubleshoot.
Now we need to modify SELinux to allow access privilege to our new Samba share. By default this is denied and users will be unable to write files to the share. Details of the SELinux configuration needed can be found in the default config file “/etc/samba/smb.conf”.
Here are some good references regarding SELinux:
Now run the SELinux config command to allow user access to the Samba share directory. New directories and files created under our Samba share directory will be automatically inherit the SELinux context of the parent directory.  Use the -R option with “chcon” to re-curse if there are existing files in the directory you are sharing:
# chcon -t samba_share_t /home/data
Now we will create a user to access the Samba share. The command options specify to add the user to a supplementary group “fileshare”, do not create a home directory, and set the login shell to “/sbin/nologin” to prevent logins to the console. We only want the user access to the Samba file share:
# useradd -G fileshare -u 1000 -M -s /sbin/nologin aaron
Assign a password to this user, although the user shouldn’t have any console login privileges:
# passwd aaron
Now we need to set up our Samba configuration file.  I will move the existing config file and create a fresh copy to be more concise. But don’t delete it, as it contains a good amount of documentation so it is a handy resource if you want to add directives later.
Move the existing file and edit the new file:
# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
# vi /etc/samba/smb.conf
Now edit the new “smb.conf” file and add parameters like this:
[global]
workgroup = WORKGROUP
server string = samba
security = user
passdb backend = tdbsam
load printers = no
[data]
comment = data directory
path = /home/data
writeable = yes
public = no
The “global” section contains directives that apply to the whole Samba instance. We can define the workgroup or domain this server is a member of, what security mechanism to use (user, share, domain), and the password database type “tdb”. The old “smbpasswd” password file is no longer recommended for use on new installations. The “load printers” directive I set to “no” because I won’t be using the CUPS printing system and connection refused errors will show up in “/var/log/messages” unless this is specified.
The 2nd section (and on if you have more than one share) has details on each Samba file share. In this case the share is named “data”, we can define if it is writeable, and “public” defines whether users not in the Samba password database can access the share.
We should test the parameters of the “smb.conf” file to make sure there are no errors:
# testparm
Once you’ve run the “testparm” command and received no errors in the output you should be set to go. You may notice that some of the parameters won’t show in the output, this is fine and indicates that some are the Samba default. We’ll now make the Samba password for the user we are adding:
# smbpasswd -a aaron
New SMB password:
Retype new SMB password:
I received a bunch of output after entering the password that you can see below. From what I can tell this not a problem and it printed a message at the bottom that the user was added. Later when I fired up Samba and connected to the share with this user everything worked normally.
tdbsam_open: Converting version 0.0 database to version 4.0.
tdbsam_convert_backup: updated /var/lib/samba/private/passdb.tdb file.
account_policy_get: tdb_fetch_uint32 failed for type 1 (min password length), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 2 (password history), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 3 (user must logon to change password), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 4 (maximum password age), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 5 (minimum password age), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 6 (lockout duration), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 7 (reset count minutes), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 8 (bad lockout attempt), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 9 (disconnect time), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 10 (refuse machine password change), returning 0
Added user aaron.
To confirm that the user was added to the Samba tdb database use the “pdbedit” command:
# pdbedit -w -L
Now we need to make changes to the “iptables” firewall startup config file. Backup the file and edit:
# cp /etc/sysconfig/iptables /etc/sysconfig/iptables.bak
# vi /etc/sysconfig/iptables
Add the first line accepting packets on TCP/445. Be sure and add it above the last line of the “input” chain with the “Reject” target, that way the rule will be processed.
-A INPUT -p tcp --dport 445 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
Now you can edit the “smb” daemon to start automatically, then start “smb”:
# chkconfig smb on
# service smb start
If you now switch over to a Samba/SMB client you should now be able to map a drive or browse the shares on the Samba server. If you want to browse the shares available you will need to manually enter something like “\\server1″ or “\\192.168.100.1″ without quotes in the address bar of Windows Explorer, the server won’t appear in Network Places. To enable full network browsing more configuration would be needed and you would probably need to enable the “nmb” daemon.