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.

Friday, 6 January 2012

Create a Shortcut to Quickly Edit Your Hosts File

As a programmer that does a lot of work on web sites, I end up having to edit my hosts file far too often, and in Windows 7 or Vista, you have to use Notepad in Administrator Mode. Tedious.
My quick and easy solution to this problem is so simple that it barely deserves a full article, but we’re going to cover it anyway—basically, you just create a shortcut to edit the file in Notepad, and set the properties to always start as Administrator. The final step is to create that shortcut in the Start Menu, so it will be easily accessible with the start menu search engine.
Once you’re done, all you have to do is type hosts into the start menu, and you can edit the Hosts file.

Let’s Make a Shortcut! 
Open up the start menu folder—Then right-click and create a shortcut, with the following location:
notepad c:\windows\system32\drivers\etc\hosts
image
Once you’ve created the shortcut, and make sure you give it a useful name like “Edit Hosts”, you should open up the shortcut properties, click the Advanced button, and then select the “Run as administrator” option.
Once you’ve done so, you can simply type hosts into the start menu to pull up the item…
You’ll be prompted to accept the UAC prompt, since you have to edit the hosts file in administrator mode.
And there we are. Edit away!
And yes, you might point out that you can simply change the permissions on the Hosts file to not require admin mode, but that would lead to a less secure system, since malware often tries to edit the hosts file.
Also, you might point out that this was such a simple and easy topic that I shouldn’t have bothered. But I did! Loss of geek points for me.

Thursday, 5 January 2012

How To Edit Your Hosts File : Snow Leopard (OS X 10.6)

In Snow Leopard, accessing the hosts file is very similar to Ubuntu. Begin in terminal and use your favorite editor, even is you wish to call a GUI text editor, it is easier to do so from terminal.
The file will look a bit more like Windows, only with a little less explanation. Again we are going to redirect Facebook.
This time it seems that 0.0.0.0 is a loopback and will direct you to the computers Apache test page.

Wednesday, 4 January 2012

How To Edit Your Hosts File : Ubuntu

In Ubuntu 10.04 and most Linux distro’s you can edit the hosts file directly in the terminal. You can use your favorite editor or even open your favorite GUI text editor. For this example we will use VIM. Like Windows 7, Ubuntu’s hosts file is located in the /etc/ folder, though here it is in the root of the drive. In order to edit the file you will need to open it as root which is why we use sudo here.
Now that it is open we can edit it to redirect Facebook into nothing. You will notice that with Ubuntu there is also a section for IP6. For most needs you will only need to edit it the top section and ignore the IP6.
Now we can save the file and try to go to Facebook.com. Just like in windows we will see that we are now redirected to a site that does not exist.

Tuesday, 3 January 2012

How To Edit Your Hosts File :Windows

Windows 7

To access the hosts file in Windows 7 you can use the following command in the Run Line to open notepad and the file.
notepad c:\windows\system32\drivers\etc\hosts
sshot-2010-08-31-[19-41-19]
Once notepad is open you can edit the file. In this example we will block Facebook. To do this just enter in the following after the # mark.
0.0.0.0    www.facebook.com
Now that you have edited your Hosts file make sure to save it.
Now notice if we try to access Facebook in IE we can’t get to the page.
.

Monday, 2 January 2012

Stop Virus entering from USB to Pc and Vice versa


In this post i am gonna tell to How to protect both PC and USB from Viruses. Well, Do you know On what moments viruses transfer from USB 2 PC and PC 2 USB????
  1. At the time when we Open USB Drive for Copying a File from USB to PC
  2. During Copying a File from PC to USB

So if we do something to stop entering Viruses on these two moments then you can protect both PC and USB from Viruses.

Now the Question arises How we can do this......
Answer:


1. At the time when we Open USB Drive for Copying a File from USB to PC

  • On this time if we disable the Writing Property of USB drive then viruses can't enter in the USB.
Now Steps to disable the Writing Property of USB drive:
1.  Click Start, click Run, type Regedit in the Open box, and then click OK.
2.  Go to HKLM > System > current control set > control
3. Right click on Control folder> new> key and give name 'StorageDevicePolicies'
4. Now In the right side window right click > new > Dwrd value and give it a value '1'
5. Now close registry, restart PC. 
2. During Copying a File from PC to USB
  • Always use 'send to' (right click on file that has to copy> send to > USB Drive) except copind and pasting file.
  • During Copying a File from PC to USB Remember to enable the Writing Property of USB drive by changing value 0 in step 4.


Direct shortcut to Enable and disable the Writing Property of USB drive 
Note: Registry Modification will be in effect only after Reboot PC.

Be safe

Friday, 30 December 2011

On-demand application delivery with Citrix XenApp

How application virtualization and session virtualization work

Citrix XenApp is an on-demand application delivery solution that comprises application virtualization and session virtualization technologies.

Understanding application virtualization

Citrix application virtualization technology isolates applications from the underlying operating system and from other applications to increase compatibility and manageability. As a modern application delivery solution, XenApp virtualizes applications via integrated application streaming and isolation technology. This application virtualization technology enables applications to be streamed from a centralized location into an isolation environment on the target device where they will execute. With XenApp, applications are not installed in the traditional sense. The application files, configuration, and settings are copied to the target device and the application execution at run time is controlled by the application virtualization layer. When executed, the application run time believes that it is interfacing directly with the operating system when, in fact, it is interfacing with a virtualization environment that proxies all requests to the operating system.

 XenApp is unique in that it is a complete system for application delivery, offering both online and offline application access through a combination of application hosting and application streaming directly to user devices. When users request an application, XenApp determines if their device is compatible and capable of running the application in question. The minimum requirements of a target device are a compatible Windows® operating system and appropriate Citrix client software. If the user device meets minimum requirements, then XenApp initiates application virtualization via application streaming directly into an isolated environment on the user’s device. In the event that the user device is not capable of running a particular application, XenApp initiates session virtualization.

Understanding session virtualization
Session virtualization uses application streaming to deliver applications to hosting servers in the datacenter. XenApp then connects the user to the server to which the application has been delivered. The application then executes entirely on the server. The user interacts with the application remotely by sending mouse-clicks and keystrokes to the server. The server then responds by sending screen updates back to the user’s device. Whereas application virtualization is limited to Windows-based operating systems at this time, session virtualization via XenApp allows any user on any operating system to access any application delivered by IT. As a result, XenApp enables Windows, Mac, Linux, UNIX, thin clients, iPhone®, Windows Mobile® devices, and even Symbian- and Java-enabled devices to run any applications using session virtualization. Furthermore, session virtualization leverages server-side processing power which liberates IT from the endless cycle of PC hardware refreshes which are typically needed to support application upgrades when using traditional application deployment methods.

Using application virtualization and session virtualization together

In both application virtualization and session virtualization, user interaction with the application is seamless. Printers, drives, peripherals, and even the clipboard work in the exact same manner as if the application were installed. As a result, XenApp reduces the cost of application management and related costs by up to 50 percent and enables a better-than-installed experience for users when compared to traditional application deployment models.

Thursday, 29 December 2011

Session initialization in Citrix

No matter how an ICA session is invoked (Program Neighborhood, Web Interface, double-clicking an ICA file, etc.), the ICA client engine (wfica32.exe for Win32 clients) fires up and loads the module.ini file from the root folder of the ICA Client. The module.ini file defines the specific capabilities that the ICA client should or can use. Therefore, when troubleshooting, it’s possible (and useful) to change settings in the module.ini to change the capabilities of the ICA Client. For example, you might chose to disable specific client drives (DisableDrives=A,D,F) or to enable server drives in a pass-through session (NativeDriveMapping=TRUE).

The following screen shot has highlighted the module.ini section where the virtual drivers that get loaded by the ICA client are specified. For testing purposes you could just choose to remove a specific virtual driver all together. This will prevent the client engine of loading the specific virtual driver, for example SmartCard, SpeechMike, ClientAudio etc.
 

Some virtual drivers (like clipboard functionality) are “built into” the client engine. Removing the word “Clipboard” from that VirtualDriver line will only disable the Clipboard on a client basis.
Once the ICA client works out which drivers it will use, it starts a connection with the server via port 1494 (even with session reliability enabled). The server responses with “7F7FICA” for an ICA handshake as shown in the next screen shot. During the handshake the client sends its list of capabilities (virtual channels supported by the client) to the server.



Next, (still before anything shows up in any admin console or on the client desktop), the TSCAL license verification is made. If the license cannot be verified then the session just ends. Even though this is by design it’s still very confusing for most people.

If the client has or gets a valid TSCAL, the server’s WinLogon.exe process calls the GINA (and any linked GINAs, like ctxgina.dll when MetaFrame is installed) and the user is presented with the logon GUI. Once the user credentials are validated via csrss.exe, WinLogon downloads the user profile. (Here is a nice article about profiles http://www.windowsitpro.com/Windows/Article/ArticleID/41654/41654.html)
The GINA then calls UserInit.exe which is responsible for setting up the user’s environment (restoring net uses, etc.). When Terminal Server is installed, UserInit queries the registry key AppSetup located in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and executes all the programs listed in that key. By default this is limited to UsrLogon.cmd, although MetaFrame XP adds cmstart.exe to the list and MetaFrame version 3 adds CtxHide UsrLogon.cmd, and CmStart.exe. (Those of you who’ve been using Terminal Server for awhile will remember that UsrLogon.com is a hold-over from the early days when application compatibility scripts were used. See Microsoft article Q195950.)
The last thing UserInit does is launch the user’s shell as specified in the registry. By default this is explorer.exe, although you can change it to whatever you want and have some fun with your colleagues by changing theirs to progman.exe.
Once the shell is fired up the final steps take place, including items listed in the run registry keys and the programs from the Startup folder.
There’s a great utility from SysInternals called “AutoRuns” that you can run on a server to quickly and graphically show you all the things that run automatically when a session is started.



Everything on the server side that we’ve mentioned so far is Microsoft only. It applies if you’re connecting via a standard Terminal Server / RDP session or via a MetaFrame ICA session, (For more detail on WinLogon, UserInit, Csrss, and other Windows processes, take a look at Microsoft Knowledge Base article Q263201.)
Now let’s take a look at what happens when Citrix is thrown in the picture. As we mentioned earler, UserInit also executes the CmStart.exe process. CmStart.exe is the Citrix Client Manager Starting Utility and it’s responsible for two things:
  1. It starts the Citrix seamless windows engine shell called wfshell.exe.
  2. It launches the Citrix Client Manager (cltmgr.exe ) that’s used to keep the ICA client up to date.
The following screenshot is of Systernals’ Process Explorer running during a MetaFrame session start.



Let’s take a closer look at these processes and what they each do.
Citrix Client Manager Starting Utility (CmStart.exe)
CmStart is responsible for launching the seamless engine which means no seamless windows without CmStart.exe in the AppSetup Key! This missing entry will not stop a desktop session from working though.

Citrix Seamless engine (wfshell.exe)
One of the things wfshell is responsible for is to autocreate the client printers. If you are using third party printer drivers (HP, Canon, Lexmark etc.) instead of original printer drivers that come on the Windows CD then you might see some of the following issues:
  • Crashes of wfshell.exe (CTX102634)
  • High CPU spikes of wfshell.exe
  • Slow logons
  • Printer being not mapped
Advice: Don’t use third party printer drivers. Instead, use mappings from the printer matrix at http://www.printingsupport.com and at least don’t use PCL6 Drivers an advice by Stefan.

Citrix Client Manager (cltmgr.exe )
Cltmgr.exe is launched right after wfshell because it uses a virtual channel (VDCM.dll, ClientManagement) to get the client version from the version.dat file. Problems with the retrieving of the ICA client version and the update might have the following effects:
  • Crashes of wfshell.exe
  • Slow logons (without updating the client)
Advice: If the Client Update feature is not used, you should disable the client update database on every Citrix server (Start | Run | cudutil.exe | Database | Properties | uncheck enable).
Session Termination
When closing a published application or logging off from a desktop session, the most important parts are terminating the user processes and unloading the user’s registry hive from the system registry.
In a desktop session the termination of the processes is done by csrss.exe. With published applications the seamless engine is responsible for closing the applications and sending the logoff message to csrss. Under certain circumstances this might not work and ends with a user’s session remaining active on the Citrix Server, although we’ll discuss this more later.
In some cases the user’s registry can not be unloaded during the logoff. This issue is very famous in the community and the solution is to use the Microsoft’s UPHClean service. (Be sure you’re using the most current version.) If the unload process doesn’t work as expected, then the profile gets stuck on the server (a bit different with Windows 2003). This then impacts the logon process, especially with anonymous users.