Showing posts with label aspnet_client. Show all posts
Showing posts with label aspnet_client. Show all posts

Saturday, August 25, 2012

Basic Cisco QoS for IP Phone System to IP Phone VoIP System Voice Garbled

Share/Save/Bookmark

Sample Cisco QoS for IP Phone System to IP Phone System to Solve Distorted Voice Quality

In this situation, the remote office's router is a Cisco 1841. The VoIP (voice) over a  legacy T1 Point-to-Point was garbled. The conversations sounded like the callers were underwater. There was need to clear up the voice quality and the best method to do so was to use QoS.  The unclear voice occurred on nearly all phone conversations both internal and external. The phone sets at the remote office were digital but the phone system is IP (VoIP) based. The remote office phone system and the phone system at the main office communicated via IP.  The simple solution, using the existing hardware already installed, for this problem was to implement QoS on the router. The goal was to prioritize the voice packets that were sent in and out of the router from one system to another. At the same time, the goal was to also keep the solution as simple as possible.

Cisco Remote Office Router - QoS class-map, policy-map, and access-list on router for Voice Quality

This simple basic QoS example firstly required a simple access list that contained both of the phone systems' ip addresses. After the simple access-list, a class-map and policy-map were also configured on the router. In the end, the policy map is applied to an interface.
 First, in configuration mode of the router,  the access-list. is created.  The access list basically will contain a lists of our phone system ip addresses for the main office and the remote.

Replace the ip addresses shown below with the ip addresses of your phone system. Also, if the access-list number is already taken on your router for another access-list, use another number. This example uses 101 for an extended access list.

   access-list 101 permit ip any host 192.168.1.10
   access-list 101 permit ip any host 192.168.2.10

 Next, create a class-map on the branch router. The class-map is basically a map or list of the match criteria. If you haven't guessed it already, the match criteria will be the ip addresses of the phone systems. In the class-map, we add "match access-group 101. 101 is the access list that contains our phone systems' ip addresses.
    class-map match-any IPPhoneSys-to-IPPhoneSys
   match access-group 101

 After the access-list and class-map is configured, the class-map is applied to the policy map. The policy map can contain more than one class-map.  So the policy-map is like a list of class-maps. The policy-map is applied to an interface. In this example it will be the serial interface corresponding to the T1 (point-to-point T1).: The bandwidth statement is key to what we are trying to accomplish. This is a simple example of QoS so I have just merely taken 20 percent of the bandwidth and pretty much assigned it to voice (VoIP)

    policy-map QoS_Policy_Priority
    class IPPhoneSys-to-IPPhoneSys
    bandwidth percent 20
    class class-default fair-queue

In this example it is a legacy point-to-point T1 that connects the two offices. The interface you use may differ. To apply the policy-map that contains the class-map with 20 percent bandwidth defined for voice change to the interface level commands by entering the interface on which you plan to apply the QoS policy map. In this example it is a serial interface for the t1 (S0/0/0)

    config# interface serial0/0/0

 Then apply the policy on the interface by running the command

    service-policy output QoS_Policy_Priority

 The above is a simple basic QoS policy using one of the many Cisco Modular QoS solutions. Once applied, it cleared the voice issues immediately. In the example above the bandwidth reserved for voice over ip (VoIP) was 20 percent. You can change that percentage to fit your environment.

QoS can be applied to all types of data streams including RDP (remote desktop protocol).  Applicable for access to server and desktop or for managing RDP.  The protocol by port number or IP address can be managed so that it's given higher priority, or lower priority if that's what the situation requires. RDP port setting can be set to a custom value on RDS servers for standard access or for managing RDP (Terminal Server). 
 

Sunday, November 20, 2011

Citrix Session Printers Registry Key Location

Session printers created via policy

Share/Save/Bookmark


Session printers created via policy in Citrix XenApp are considered local printers. As such they are in the registry key that is common for local printer definitions. That registry key location on Windows 2008 R2 is :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers

Problem with session printers such as additional printers appearing in the user's list of available printers while in a session, most often is a result of driver corruption. Once the corrupt driver has been fixed or removed, you may have printers still showing up in user sessions that do not belong.

One of the things you can check is the key in the registry where the session printers are defined.
For stuck printers, as option to get rid of them is often to delete the user's profile but that's not always the best option so removing the session printers defined for that user can be done through the registry. Be cautious when removing but when there are no users logged into the Cirix Xenapp server, there should be no session printers defined.

Similar to Citrix is RDS using RDP protocol. Similar issues are encountered when using RDP for user access to desktops or Administrator access to servers or desktops. Managing RDP connections can be time consuming and having a centralized RDP connections make administration and management easier. RDS gateway such as this one similarly to Citrix permits multiuser access. 

Saturday, February 16, 2008

VMware Boot From ISO Image

VMware-boot-from-iso-image-2
Share/Save/Bookmark

One of the nice features of VMware workstation is the feature that gives the user of the the software the ability to boot from an ISO image. This is a great feature and another display of some of the great thought put into this application. If the computer on which VMWare workstation doesn't have a DVD player for example, the ISO image stored on the hard-drive of the host computer or on a network drive can be used to start the installation. The ISO image is read and if it's the installation media for Vista for example, the installation begins. The guest operating system once installed and during the installation doesn't even "know" that's it's being run virtualized. This is a wonderful feature of VMWare workstation and I often find myself asking why didn't this solution come out many years ago as it's a terrific aid for testing and support of applications. With separate operating systems, virtual of course, tests can be run much easier as there's really no restore to perform or drive swapping like in the old days to bring the system back to a state for a re-test.  Some issues can be resolved using RDP. RDS Gateways and Hosts use RDP and permit access to server with RDP enabled