Defrag Multiple Hard Drives At Once In Windows

The Disk Defragment utility in Windows XP does not include a way to defragment all hard drives at the same time, which is inconvienient when you have more than one hard drive in your computer.

The method we are going to use is by creating a batch file to defragment all of the drives, one after the other.

The disk defrag utility in Windows XP can be triggered from the command line with the following syntax:

Windows Disk Defragmenter
Copyright (c) 2001 Microsoft Corp. and Executive Software International, Inc.
Usage:
defrag <volume> [-a] [-f] [-v] [-?]
  volume  drive letter or mount point (d: or d:\vol\mountpoint)
  -a      Analyze only
  -f      Force defragmentation even if free space is low
  -v      Verbose output
  -?      Display this help text

First, we’ll create a file named defragall.bat, and place it anywhere you like, as long as you’ll remember where it is. If you want to run it from the command line, you could place it in the \windows directory so that it will be available in the system path.

For each hard drive, add a line to the batch file. For instance, if we want to defragment drives C: , D: , and F: we will add these three lines:

defrag c: -f
defrag d: -f
defrag f: -f

To run the defrag, just either double-click on the batch file or start it from the command line.

Auto Deletion of Temporary Folder

You can set the computer to delete automatically your files in temporary folder. 

To do that click Run from start menu and type gpedit.msc 

and click OK. 

And select Computer Configuration/Administrative Templates/Windows Components/Terminal Services/Temporary Folder.

Then right click "Do Not Delete Temp Folder Upon Exit" 

Go to properties and select disable

Allow Remote Control To Your Desktop On Ubuntu

Enabling remote desktop mode is extremely easy on Ubuntu since Dapper. You can allow other users to access your desktop using the VNC Viewer utility that is bundled with Ubuntu, or offered as a free download for Windows.

Note that enabling remote control of your desktop is never a safe thing to do unless you have a firewall installed and configured correctly, and even then is still a potential security problem. Now that you’ve been warned of the risks, let’s move on.

Navigate to the System \ Preferences \ Remote Desktop on the Gnome top menu.

You’ll see this window:

The first two checkboxes need to be checked in order for remote desktop to be enabled.

The Security section is important: If you select the “Ask you for confirmation” code, then you will need to be at the computer in order to allow the other person to access your desktop. If you are trying to remotely access one of your own computers, you will want to uncheck this box.

The second checkbox should always be checked, and you should enter a secure password. You will be prompted for this password when you try to log on.

Tested on: Ubuntu Dapper Drake, Ubuntu Edgy Eft

Memory/CPU Optimization in Citrix

Citrix Presentation Server 4.0 introduced two resource optimization features that help increase scalability by as much as 25% and ensure a smoother user experience. These two features, memory optimization and CPU optimization, are distinct and function in unique ways. Memory and CPU optimization are not enabled by default.

Memory Optimization

When an application starts, the operating system maps application DLLs to the base memory address space. The default base memory address of applications is 0x10000000. Memory optimization works by redirecting the base memory address of applications to an alternate location. When multiple applications start and try to write to this base memory address and find it already in use, they must be relocated elsewhere. In doing so, the module code must be modified and produces a performance hit on application initialization time.With memory optimization invoked, the base memory addresses of installed applications are rebased at a predefined interval. This means that the base memory address is altered, and as such, the applications are relocated to another address automatically during initialization. The end result is that applications load faster because intermediate redirection.


During the predefined memory rebasing interval, a safe memory base address is calculated and designated. Thus, the 0x10000000 address is altered. The memory rebasing interval is set within the server farm properties, and should be scheduled during times of minimal use. Options are: startup, daily, weekly, or monthly. By default, the files listed in the HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SFO\ProcessExclusionList registry key are excluded from rebasing. Additional applications can be excluded from memory rebasing by being added to the exclusion list within farm properties memory optimization. Once added in the GUI, they will also be added to this registry key. The repair.sfo file includes the files that have been rebased, and the timestamp of the rebased DLLs will be modified to reflect the approximate time of the rebasing interval.

Some applications cannot be rebased. These include applications with digitally signed components, DLLs protected by Windows Rights Management, and any executable that programmatically checks the DLL after it has been loaded. However, even if an application is not included on the exclusion list, it simply means that rebasing will be attempted but will not be successful. Since rebasing should be scheduled during a time of minimal server use, the resource impact of the attempted rebasing should not be noticeable.

Memory optimization is based on the Citrix Virtual Memory Optimization service. This Windows service scans loaded DLLs every 10 seconds to determine which DLLs have been relocated. By default, this service runs under the context of the local system account but can be modified within farm properties.

The graphic shown below shows that without memory optimization invoked, all applications attempt to write to the same base memory address space, whereas with memory optimization invoked, each application cleanly gets directed to a unique address space.

Without Memory Optimization Configured

 

 With Memory Optimization Configured

 

CPU Optimization
CPU optimization is based on Presentation Server reserving approximately 20% of the CPUs for automatic optimization. As a result, no single session controls the majority of CPU processing. However, CPU power can be borrowed from idle or inactive sessions but re-allocated when active again.

CPU optimization is based on two Windows services:

• Citrix CPU Utilization Mgmt/Resource Mgmt: Monitors users and processes, calculates load, and sets CPU priority.
• Citrix CPU Utilization Mgmt/ User-Session Sync: Ensures that user processes get associated with user to determine load.

Impact to Architectural Designs

Invoking memory and CPU optimization is typically beneficial and should not have any noticeable negative impact. Memory optimization should be scheduled during a time of low or no usage. If an administrator is uncertain as to whether specific applications cannot take advantage of this feature, they should not be added to the exclusion list. Only those applications which have known issues based on the criteria described above should be placed on the exclusion list. Because CPU optimization uses approximately 20% of the CPU processing power, older servers with limited CPU resources may not have sufficient CPU to support this feature.

Considerations

As part of the application testing process, memory and CPU optimization should be tested to ensure that there is no adverse impact to the environment.

The impact of memory and CPU optimization can be viewed in standard Access Suite Console reports. In addition, CPU utilization can be viewed within the new Citrix CPU Utilization Mgmt User object, which can be accessed via Resource Manager or Performance Monitor. This object includes the following counters: CPU entitlement, CPU reservations, CPU shares, CPU usage, and long-term CPU usage.

Making Virtual IP Addresses Available to Applications in Citrix

Some applications, such as CRM and CTI, use an IP address for addressing, licensing, identification, or other purposes and thus require a unique IP address or a loopback address in sessions. Other applications may bind to a static port, which, because the port is already in use, causes the failure of multiple attempts to launch an application in a multiuser environment. For such applications to function correctly in a XenApp environment, a unique IP address is required for each device.

Use the virtual IP address feature to assign a static range of IP addresses to a server and have these addresses individually allocated to each session so that configured applications running within that session appear to have a unique address.

Processes require virtual IP if either:

• They use a hard-coded TCP port number, or
• They do both of the following:
  • Use Windows sockets, and
  • Require a unique IP address or require a specified TCP port number

Also, this feature lets you configure applications that depend on communication with localhost (127.0.0.1 by default) to use a unique virtual loopback address in the localhost range (127.*).
Processes require virtual loopback if either:

• They use the Windows socket loopback (localhost) address (127.0.0.1), or
• They use a hard-coded TCP port number

If the application requires an IP address for identification purposes only, configure your server to use the client IP address.

How Virtual IP Addressing Works

The virtual IP Address feature works as follows:

• During IMA startup, the virtual IP address assigner binds the assigned IP addresses to the NIC that matches the same subnet as the virtual addresses.
• When the virtual IP feature is enabled on a specific server, the virtual IP address allocator allocates all new sessions connecting to the server an address from   the  pool of available addresses that were assigned by the virtual IP address assigner.
• Each new session is allocated an address that is removed from the pool of available addresses. When the session logs off, the allocated address is returned to the available address pool.
• After an address is allocated to a session, it uses the allocated virtual address rather than the primary IP address for the system whenever the following calls are made:

  Bind¸closesocket¸connect, WSAConnect, WSAAccept, getpeername,
  getsockname, sendto, WSASendTo, WSASocketW, gethostbyname,
  gethostbyaddr, getnameinfo, getaddrinfo

Note: All processes that require this feature must be added to the Virtual IP Process list. Child processes do not inherit this functionality automatically. Processes can be configured with full paths or just the executable name. For security reasons, Citrix recommends that you use full paths.

 

To make virtual IP addresses available to aplications running in sessions

Use virtual IP addresses to provide published applications with unique IP addresses for use in sessions. This is especially important for Computer Telephony Integration (CTI) applications that are widely used in call centers.

Users of these applications can access them on a XenApp server in the same fashion that they access any other published application.

To assign virtual IP address ranges, you must have a reserved range of static IP addresses to assign to the server. Work with your network administrator to obtain a list of free addresses that are not part of your DHCP pool. Ensure that you do not include broadcast addresses.

Before assigning virtual IP address ranges, determine the maximum number of users you may have connecting concurrently to the server. Because every session connecting to the server is assigned an IP address (not just sessions launching the application that require virtual IP addresses), assign at least as many static IP addresses to the server as the maximum number of users who may be connecting concurrently to that server.

 

Note: In the event more sessions are launched on a server than IP addresses are available, the server displays the error message: “No virtual IP address is available for this session, please contact your administrator.” The inability of the server to assign a virtual IP address to a session does not prevent the user from launching an application that requires a virtual IP address within the session; however, the application may not function correctly.

• At the farm level, configure virtual IP address ranges and assign them to servers.
• Enable applications to use virtual IP addresses.

In addition to configuring virtual IP address ranges and enabling applications for use with virtual IP addresses, this feature can control and monitor virtual IP addresses available from each server.

 

To determine whether an application needs to use virtual IP addresses

Some applications cannot run in multiple sessions on XenApp. For example, if the application binds to a fixed TCP port on a specific IP address such as 0.0.0.0 or 127.0.0.1, this prevents multiple instances of the application from running in multiple sessions because the port is already in use. The virtual IP feature of XenApp can help solve this problem.

To determine whether or not the application needs to use virtual IP addresses:

1. Obtain the TCPView tool from Microsoft. This tool lists all applications that bind specific IP addresses and ports.
2. Disable the Resolve IP Addresses feature so that you see the addresses instead of host names.
3. Launch the application and, using TCPView, note which IP addresses and ports are opened by the application and which process names are opening these ports.

To use the virtual IP address feature, configure any processes that open the IP address of the server, 0.0.0.0, or 127.0.0.1. To ensure that an application does not open the same IP address on a different port, launch an additional instance of the application.