User is unable to take print, while printing user is getting error massage

To resolve this issue need to download "VSPDF.OCX" and VSPRINT7.OCX" from internet and paste it in c:\windows\system32 that register in registry through below command :-
c:\regsvr32 filename
c:\regsvr32 VSprint7.ocx
c:\regsvr32 vspdf.ocx

These fileds are Activex controllers.

https://picasaweb.google.com/104024887167449947215/CitrixMaster?authkey=Gv1sRgCJPWi8265oWzpAE#5623595769052419410

The SSL Server You Have Selected is not accepting connections

Troubleshooting “The SSL Server You Have Selected is not accepting connections” error message

Make sure that a connection is being made to the server running Secure Gateway.

• Set the logging to maximum on Secure Gateway so that all events, including informational, are logged.

• Attempt to connect.

• Make sure that there is a connection in the application log on the server running Secure Gateway:

CSG0401 Accepted connection from client >client ip address<.

• If no connection is logged in the event viewer, make sure that Secure Gateway is started and that the firewall is allowing access to that server.

• Make sure the client can resolve the FQDN of the server running Secure Gateway.

• If you are attempting to use IIS and Secure Gateway on the same server, make sure you followed CTX799332 - Running Citrix Secure Gateway and IIS/NFuse on the same server ; there are two IP addresses, each with its own SSL certificate; and Debug.asp CTX052061 - Citrix Web Server Debugging & Analysis Tool shows that DisableSocketPooling is set to True. Verify that IIS is not trying to run a Web site on the same IP address as Secure Gateway.

Ensure that the server running Secure Gateway can access the MetaFrame server on the IP address specified.

• Set the logging to maximum on the server running Secure Ticket Authority (STA) so that all events, including informational, are logged by editing the ctxsta.config file and changing the logging level to 3. Then run IISRESET.

• Attempt to connect.

• Check the STA logs to see what address the STA is sending to the server running Secure Gateway  they are in the \inetpub\scripts folder by default.

Check for an entry resembling this:

INFORMATION 2002\11\15:14:24:54 CSG1305 Request Ticket - Successful 97CA7F83085BD179B08EDC1F0DC316FC MetaFrame address:port

• The server running Secure Gateway must be able to access the given IP address on the port specified.

To test, telnet to that address from Secure Gateway or make a connection using the Citrix ICA Client.

If the server running Secure Gateway and the MetaFrame server are separated by a firewall performing Network Address Translation (NAT), you may need to configure an alternate address on the MetaFrame server and then set Use alternate addresses of MetaFrame servers in the server-side firewalls settings. The internal firewall must be configured to allow the traffic on port 1494 from the server running Secure Gateway to the MetaFrame server.

Additional Information

CTX103343 - Error: Cannot connect to the Citrix MetaFrame Server. Server location address must be specified as fully qualified domain names to allow SSL connections to succeed.

The Citrix SSL relay name could not be resolved (SSL error 40)

Symptom

Users receive the following error message when trying to launch applications through Secure Gateway:

“Cannot connect to the Citrix server:
The Citrix SSL relay name could not be resolved (SSL error 40)”

Cause

The fully qualified domain name (FQDN) of the Secure Gateway server is not recognized by the client.

Reason

A DNS record was not made to resolve the FQDN name of the gateway

— or —

The FQDN of the Secure Gateway server entered in Web Interface/NFuseAdmin/server-side firewall/Secure Gateway for MetaFrame does not match the name on the certificate of the Secure Gateway server.

Resolution

Create a DNS record that resolves the FQDN of the Secure Gateway server or create an entry in the host file on the client devices.

Verify that the FQDN referenced in Web Interface/NFuseAdmin/server-side firewall/Secure Gateway for MetaFrame matches the name on the certificate of the Secure Gateway server.



This document applies to

Troubleshooting SSL Error 4 with Secure Gateway

Symptoms

A SSL 4 error when connecting to an application through Secure Gateway usually indicates a connection issue between one or more of the components that make up Secure Gateway.

Resolution

Set logging levels to maximum on the CSG server and the STA Server

Check the logs after SSL Error 4 occurs on the client machine.

On the CSG Server:

1. Ensure the client is connecting to CSG:

• If one sees a client connect in CSG logs, check the STA logs

• If there is no client connect, verify that the Secure Gateway is running and that the IP address it is bound to is the one that the client is resolving from the FQDN.

2. Check the Citrix Secure Gateway Servers Event Viewer’s Application, System, and Secure Gateway Logs. One installation showed some of the following:

"Event Type: Error
Event Source: Secure Gateway
Event Category: CORE
Event ID: 100
Date: 10/22/2007
Time: 7:45:43 PM
User: N/A
Computer: YourServerName
Description: An internal server error occurred."

"Event Type: Information
Event Source: Application Error
Event Category: (100)
Event ID: 1004 or 1000
Date: 10/22/2007
Time: 7:26:49 PM
User: N/A
Computer: YourServerName
Description: Reporting queued error: faulting application CtxSGSvc.exe, version 3.0.0.43994, faulting module libapr.dll, version 3.0.0.43994, fault address 0x0000cc7e.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 43 74 78 ure Ctx
0018: 53 47 53 76 63 2e 65 78 SGSvc.ex
0020: 65 20 33 2e 30 2e 30 2e e 3.0.0.
0028: 34 33 39 39 34 20 69 6e 43994 in
0030: 20 6c 69 62 61 70 72 2e libapr.
0038: 64 6c 6c 20 33 2e 30 2e dll 3.0.
0040: 30 2e 34 33 39 39 34 20 0.43994
0048: 61 74 20 6f 66 66 73 65 at offse
0050: 74 20 30 30 30 30 63 63 t 0000cc
0058: 37 65 7e "

"Event Type: Error
Event Source: Secure Gateway
Event Category: None
Event ID: 3299
Date: 10/22/2007
Time: 3:08:59 PM
User: N/A
Computer: YourServerName
Description: The Citrix service named Secure Gateway reported the following error:
>>> CtxSGSvc.exe: could not open document config file E:/Program Files/Citrix/Secure Gateway/conf/httpd.conf"

When NTSD was enabled, CTX105888 – How to Set the NT Symbolic Debugger as a Default Windows Postmortem Debugger, CtxSGSvc.exe trapped every time a connection was attempted. In this case, this was a new installation. CTX114059 – Hotfix SGE300W008 - For Citrix Secure Gateway 3.0 did not resolve the issue. Citrix Secure Gateway was uninstalled from E: and installed to C:. After the reinstall, Citrix Secure Gateway functioned as designed.

On the STA Server:

Check for Request Data successful for each Request Ticket successful

• If we see Request Data Successful CSG can connect to the STA

• If there is no Request Data Successful, CSG did not validate the ticket

• Check the Web Interface Configuration and the Secure Gateway configuration to verify they are pointing to the same STA server.

• Verify connectivity between the CSG server and the STA server using the transport protocol designated in the configuration (http / https)

Verify ICA Connectivity:

Verify that the CSG server can communicate to the MetaFrame server on port 1494 either by setting up an ICA client connection or doing a telnet to port 1494 of the server that was indicated in the STA log.

How does AIE work?

A standard Windows application consists of many parts that normally would spread across your system in places like C:\Program Files, C:\Windows, C:\Windows\System32, as well as the HKCU and HKLM registry hives. In a nutshell, AIE redirects the files and registry values of an application installation to an “Isolation Environment” which is managed through the Presentation Server Management Console. Then when the application is run, AIE makes the application believe it’s running from the location you entered at installation time like “C:\Program Files\Application Name” when in fact the complete application code is actually in “C:\ProgramFiles\Citrix\AIE\Application Name.”

A similar process is used to redirect the application’s registry settings. An application installation that would normally create settings in a registry key like “HKLM\Software\Your App Vendor” and “HKCU\Software\Your App Vendor.” Using AIE it’s now redirected to “HKLM\Citrix\AIE\Your App Vendor” and “HKCU\Citrix\AIE\Your App Vendor.” Again AIE makes the application believe its registry keys are in HKLM\Software\Your App Vendor and HKCU\Software\AIE\Your App Vendor.

The AIE feature of PS4 can be used in two ways:
You can Install and then Run an application in AIE
You can run a “normally” installed application in an AIE.

In both cases the first thing you need to do is create an AIE.

Creating an AIE

For each application you want to isolate you need to create a separate Isolation Environment. This is done from “Isolation Environments” node in the Presentation Server Management Console. Right click it, choose “New” and type in a name for your AIE. This only needs to be done once for each Server Farm.



You are now ready to either install or run an application in the AIE.

Installing into and Running from an AIE

There are two ways to install an application into an AIE. This can be done in an automated way via Installation Manager or manually using the AIESETUP executable with the appropriate parameters.

Installing to an AIE through Installation Manager is pretty easy. Simply select the .MSI of .WFS file like you would normally do and in the “Schedule Job” screen you now have the option to select in which “Isolation Environment” you want to install the application to.

Using the AIESETUP command is a little more work but is the best way to really get familiar with AIE. The syntax of this command is pretty easy. (Type AIESETUP /? to see the options.) In the following example I will install Acrobat Reader into an AIE called “Acrobat Reader” with an Installer named “c:\AdbeRdr70_enu.exe”.

AIESETUP "Acrobat Reader" c:\AdbeRdr70_enu.exe

The setup starts and I decide to install to C:\Program Files\Adobe\Acrobat 7.0\



I’m actually monitoring the C:\Program Files\ folder while the installation is taking place. I don’t see an Adobe folder appearing. Also after the installation finishes successfully no Adobe folder is present under C:\Program Files\. All Files and Registry have been redirected. Here’s the folder where the application files actually are present:





The reason you see 3 folders here is because this application installs files outside the entered installation path. This includes Shortcuts, Common Files, a couple of DLL’s in the Windows Folder, etc. This is proof that everything an application tries to do is redirected and not only the installation path of an application.

Now that the application has been installed, you need to run it. There are two ways this can be done:
You can publish AIE applications
You can run them via a special command line

Publishing an AIE application is fairly straightforward. You simply publish it through the Presentation Server Console and in the “Specify what to publish” screen select “Isolate Application.” Then click on settings, select the correct AIE, select “Application was installed into environment” and select the appropriate shortcut from the dropdown menu. The rest is the same as “normal” application publishing. Now you can run the application from a Citrix client.



The second way of running the application is through the AIERUN executable command. This is the way you would run an AIE application from the console or from a published desktop .

To do this I run the application using the AIERUN executable command with a very long parameter:

AIERUN.EXE “Acrobat Reader” “C:\Program Files\Citrix\AIE\Acrobat Reader\Device\C\Program Files\Adobe\Acrobat 7.0\Reader\Acrord32.exe”

If you want to provide your users access to this application from a published desktop then simply create a shortcut to the AIERUN command as shown above.

The application starts. Now from within the application I browse (through File -> Open) to C:\Program Files\ and here I see the Virtualized (redirected) folder Adobe.
From the regular Windows Explorer I still don’t see the Adobe folder under C:\Program Files\.



The Isolation Environment is actually a basic form of application virtualization since the AIE makes the OS and the application executable think it’s running from its native location. (Notice I say it’s a “form” of virtualization. It’s actually very different than “true” virtualization that companies like Softricity provide.)

Running a “normally” installed application in an AIE

The second way of working with AIE is to run a “normally” installed application in AIE. This can solve a lot of multi-user application issues such as when an application stores user-specific settings in Local Machine registry. AIE really can help you with these kinds of situations.

First of you have to create an AIE in the Presentation Server Console as mentioned earlier in which you won’t install any application code. Then you can either publish the application or run it with the AIERUN command. When publishing through the PSC in the “Specify what to publish” screen simply browse to the already installed executable and then select in which AIE you want it to run.

For demonstration purposes I created an AIE named “User Settings Demo.” I published regedt32.exe and selected the AIE “User Settings Demo.” Now I run the published application with an ICA Client from the server console. I also start regedt32.exe from the server console. (Keep in mind that the Local Machine registry is the same from the server console as from within a published application as long you’re running on the same server, which I am.) During the logon script for the published application I create two empty subkeys under HKLM\Software named “usersetting1” and “usersetting2”. This is what a “bad” application could do during startup or while working with the application. The following is the result:



The left is the registry editor running on the server console. The right is the registry editor running through a published application on the same server at the same time .

The new registry keys I just created are actually saved in the user’s registry under HKCU\Software\Citrix\AIE\%AIENAME% even though for the application they appear to be under the HKLM\Software registry. This means machine settings are saved per user from now on and multiple concurrent users on the same server can have different machine settings.

What will not work with AIE?

AIE is great, but of course there are limitations. (I think we will find out in the field the hard way what the “real” limitations are.)

OS patches, drivers, and really deeply integrating applications probably won’t work, especially installing into an AIE. (Although all application isolation, virtualization, and redirection software I’ve come across have some sort of limitations like these.)

What can AIE solve?

Application Conflicts
Run multiple version of the same application
Run multiple version of the same DLL

Multi User Issues
Solves configuration issues with hard coded path to .INI files
Solves configuration issues with HKLM registry keys