Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Install client Application in Citrix Xenapp server
Install client Application in Citrix Xenapp server
We have business server application installed in windows 2008 that has its SQL database in separate windows 2008 server
Users work remotely, I need to install the client application in Citrix Xenapp Server, so that when users click on the icon of the Application it will open up their Login window (which is Active Directory login) then they can login and open up the application, the data they add or change in the application will get saved in SQL database server.
Well, From Citrix standpoint, what do I need to install in Citrix Xenapp servers ?
Thanks
We have business server application installed in windows 2008 that has its SQL database in separate windows 2008 server
Users work remotely, I need to install the client application in Citrix Xenapp Server, so that when users click on the icon of the Application it will open up their Login window (which is Active Directory login) then they can login and open up the application, the data they add or change in the application will get saved in SQL database server.
Well, From Citrix standpoint, what do I need to install in Citrix Xenapp servers ?
Thanks
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
The client application (probably 32 bit)
The corresponding ODBC information pointing to the database.
On a workstation device, this will probably be located under
HKLM\SOFTWARE\MICROSOFT\OD
Export this information
You need to import it to the HKLM\WOW6432\SOFTWARE\MICR
The driver for SQL should already exist.
In some cases you must install the client tools for the version of SQL used but that is rare.
The corresponding ODBC information pointing to the database.
On a workstation device, this will probably be located under
HKLM\SOFTWARE\MICROSOFT\OD
Export this information
You need to import it to the HKLM\WOW6432\SOFTWARE\MICR
The driver for SQL should already exist.
In some cases you must install the client tools for the version of SQL used but that is rare.
Brian Murphy
I mean on Citrix Xenapp server
Do I need to install ODBC on Xenapp server then open up ODBC and create/configure DSN that points to SQL server and the proper database?
I do not understand when you day "Export Information " and the rest ?
Can you please lay out the necessary steps , so that I do not get confused ?
Thanks
I mean on Citrix Xenapp server
Do I need to install ODBC on Xenapp server then open up ODBC and create/configure DSN that points to SQL server and the proper database?
I do not understand when you day "Export Information " and the rest ?
Can you please lay out the necessary steps , so that I do not get confused ?
Thanks
It depends on the application. All I'm saying is from a working workstation export this key from Regedit using Start > Run > regedit32.exe > Enter.
Export the HKLM key to a text file
Remove anything not required for connectivity
If there is nothing under ODBC Key structure then it does not sound like System DSN.
This can go many directions at this point.
Some older applications retain .INI file instead of registry.
If you want to know what the working program simply download System Internal process monitor.
What I'm attempting to say is merely a guess, at best. Thick client applications can use .NET Framework on the local machine, they can use pass-through authentication, they can have separate accounts in the SQL Table.
A more common option is ODBC. ODBC is not something to install, it exists.
The other factor is your client Operating System. If the application runs on Window 7 32 Bit, as one example of many. The ODBC tool is located in Windows 7 32 Bit at c:\windows\system32\odbc32
Here are the registry keys based on the assumption it does use ODBC..
STANDARD 32 BIT WORKSTATION
HKEY_LOCAL_MACHINE\Softwar
HKEY_CURRENT_USER\Software
32 BIT ODBC LOCATED IN C:\WINDOWS\SYSTEM32 WITH 2008 64 BIT OS
HKEY_LOCAL_MACHINE\Softwar
cKEY_CURRENT_USER\Software
Every DSN the connection back to SQL The GUI represents the registry aforementioned Regedit Folders (keys).
This is one of many authentication methods. Particularly if there is a web server sitting between the thick client and backend database.
The steps are too many so here is an example of porting over to 64 Bir
http://wikis.openlinksw.com/UdaWikiWeb/Win32vs64OdbcAdmin
Your exported file will look something lie:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWA
"Driver"="C:\\WINDOWS\\sys
"Server"="10.1.1.1"
"Database"="MY_DB"
"LastUser"="db_account"
[HKEY_LOCAL_MACHINE\SOFTWA
"MY_DB"="SQL Server"
Notice above, all it is one ODBC created and stored in the registy.
On ODBC.INI folder, to to File > Export
Rename the file to myodbc.reg. Copy to 2008 Server, Import registry key by double clicking
This would eliminate that issue but there are many others that cause this as well.
See this article to determine if that is your issue. This is the fastest and easier one to fix.
http://help.bluemangolearning.com/m/screensteps-workgroup/l/17300-creating-odbc-connections-on-windows
If that key does have information, review this Video
https://www.youtube.com/watch?v=tUiaK5fRH7k
Export the HKLM key to a text file
Remove anything not required for connectivity
If there is nothing under ODBC Key structure then it does not sound like System DSN.
This can go many directions at this point.
Some older applications retain .INI file instead of registry.
If you want to know what the working program simply download System Internal process monitor.
What I'm attempting to say is merely a guess, at best. Thick client applications can use .NET Framework on the local machine, they can use pass-through authentication, they can have separate accounts in the SQL Table.
A more common option is ODBC. ODBC is not something to install, it exists.
The other factor is your client Operating System. If the application runs on Window 7 32 Bit, as one example of many. The ODBC tool is located in Windows 7 32 Bit at c:\windows\system32\odbc32
Here are the registry keys based on the assumption it does use ODBC..
STANDARD 32 BIT WORKSTATION
HKEY_LOCAL_MACHINE\Softwar
HKEY_CURRENT_USER\Software
32 BIT ODBC LOCATED IN C:\WINDOWS\SYSTEM32 WITH 2008 64 BIT OS
HKEY_LOCAL_MACHINE\Softwar
cKEY_CURRENT_USER\Software
Every DSN the connection back to SQL The GUI represents the registry aforementioned Regedit Folders (keys).
This is one of many authentication methods. Particularly if there is a web server sitting between the thick client and backend database.
The steps are too many so here is an example of porting over to 64 Bir
http://wikis.openlinksw.com/UdaWikiWeb/Win32vs64OdbcAdmin
Your exported file will look something lie:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWA
"Driver"="C:\\WINDOWS\\sys
"Server"="10.1.1.1"
"Database"="MY_DB"
"LastUser"="db_account"
[HKEY_LOCAL_MACHINE\SOFTWA
"MY_DB"="SQL Server"
Notice above, all it is one ODBC created and stored in the registy.
On ODBC.INI folder, to to File > Export
Rename the file to myodbc.reg. Copy to 2008 Server, Import registry key by double clicking
This would eliminate that issue but there are many others that cause this as well.
See this article to determine if that is your issue. This is the fastest and easier one to fix.
http://help.bluemangolearning.com/m/screensteps-workgroup/l/17300-creating-odbc-connections-on-windows
If that key does have information, review this Video
https://www.youtube.com/watch?v=tUiaK5fRH7k
I have published some flat applications and I did not have to export or import any registery key. example word,excel,etc...
howevere some applications are 3 tier apps, they consists of:
Database server, Application server, and Application Client.
On Citrix Xenapp, all we need is the Application client to be installed. in this case I wonder if anything else will go with that Application.
howevere some applications are 3 tier apps, they consists of:
Database server, Application server, and Application Client.
On Citrix Xenapp, all we need is the Application client to be installed. in this case I wonder if anything else will go with that Application.
I believe the way you install an application on Workstation, you will install it the same way on Xenapp Server.
if it requires ODBC install on the workstation, you will install ODBC on Xenapp server.
if it requires ODBC install on the workstation, you will install ODBC on Xenapp server.
You stated workstation application that uses SQL?
And SQL was separate.
Unless you believe in magic, there is something telling the application to use SQL.
Most of the time that is an ODBC / DSN.
Second place is the SQL Client installed but more than likely still uses a DSN
Third is a DSN File which is the same as ODBC but in a binary file located on the hard drive
4th is a .INI file that points to a DSN on the hard drive or might have an ENTRY called Database: SQL
And the NAME of the SQL Server.
You can find this out by downloading Wireshark from www.wireshark.org
If you prefer something quicker then download TCPVIEW from Microsoft System Internals
If you prefer something faster than that open CMD Prompt and type:
netstat -a | find /i "1433"
or
netstat -a | find /i "sql"
or
netstat -np <protocol> | find "port #"
In other words;
netstat -np TCP | find "1433"
Example
netstat -np TCP | find "80"
Press Enter
TCP 192.168.0.105:50466 64.34.119.101:80 ESTABLISHED
TCP 192.168.0.105:50496 64.34.119.101:80 ESTABLISHED
If that application uses SQL, it will be 1433.
If it uses INSTANCE Name it might be 1434
If it is SQL 2012 it might use a "Dynamic Port"
Another way of finding foreign port is
netstat -an | findstr ":N[^:]*$"
Where N is the port number you are interested in.
-n ensures all ports will be numerical, i.e. not returned as translated to service names.
-a will ensure you search all connections (TCP, UDP, listening...)
In the find string you must include the colon, as the port qualifier, otherwise the number may match either local or foreign addresses.
You can further narrow narrow the search using other netstat switches as necessary...
And SQL was separate.
Unless you believe in magic, there is something telling the application to use SQL.
Most of the time that is an ODBC / DSN.
Second place is the SQL Client installed but more than likely still uses a DSN
Third is a DSN File which is the same as ODBC but in a binary file located on the hard drive
4th is a .INI file that points to a DSN on the hard drive or might have an ENTRY called Database: SQL
And the NAME of the SQL Server.
You can find this out by downloading Wireshark from www.wireshark.org
If you prefer something quicker then download TCPVIEW from Microsoft System Internals
If you prefer something faster than that open CMD Prompt and type:
netstat -a | find /i "1433"
or
netstat -a | find /i "sql"
or
netstat -np <protocol> | find "port #"
In other words;
netstat -np TCP | find "1433"
Example
netstat -np TCP | find "80"
Press Enter
TCP 192.168.0.105:50466 64.34.119.101:80 ESTABLISHED
TCP 192.168.0.105:50496 64.34.119.101:80 ESTABLISHED
If that application uses SQL, it will be 1433.
If it uses INSTANCE Name it might be 1434
If it is SQL 2012 it might use a "Dynamic Port"
Another way of finding foreign port is
netstat -an | findstr ":N[^:]*$"
Where N is the port number you are interested in.
-n ensures all ports will be numerical, i.e. not returned as translated to service names.
-a will ensure you search all connections (TCP, UDP, listening...)
In the find string you must include the colon, as the port qualifier, otherwise the number may match either local or foreign addresses.
You can further narrow narrow the search using other netstat switches as necessary...
Brian Murphy
you misunderstood my statement
let 's forget about Citrix for a moment.
If you have a server application on wondows 2008 and SQL Database on another windows 2008, all you need to install on Windows 7 is the Client Application and probably the ODBC.
now let 's go back to the picture where Citrix Xenapp server is implemented, you will do the same install as the one done on windows7 , install the client application and probably ODBC.. That way you do not need to install anything on windows workstations other than Citrix Client(receiver)
Correct?
you misunderstood my statement
let 's forget about Citrix for a moment.
If you have a server application on wondows 2008 and SQL Database on another windows 2008, all you need to install on Windows 7 is the Client Application and probably the ODBC.
now let 's go back to the picture where Citrix Xenapp server is implemented, you will do the same install as the one done on windows7 , install the client application and probably ODBC.. That way you do not need to install anything on windows workstations other than Citrix Client(receiver)
Correct?
Brian's answered your question a couple of times. Yes, you install the client on the XenApp server same as you would a Windows 7 workstation. How that client communicates with SQL and how you configure that communication per user that connects to the XenApp server is the caveat. Brian has covered that well also.
The client application HAS to be told HOW to communicate with the SQL Server. The HOW is what Brian is trying to get you to understand.
SOME client applications will configure the connection to the SQL Server at install time. Others will require a manual setup.
When you install the client application on a Windows 7 computer, does the install process configure the connection to the SQL Server? If not, how do you configure the Windows 7 application to point to or use the SQL database it needs?
You should be able to use the exact same process on a XenApp server.
SOME client applications will configure the connection to the SQL Server at install time. Others will require a manual setup.
When you install the client application on a Windows 7 computer, does the install process configure the connection to the SQL Server? If not, how do you configure the Windows 7 application to point to or use the SQL database it needs?
You should be able to use the exact same process on a XenApp server.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial