9 Replies Latest reply: Feb 16, 2012 9:14 AM by Mark Walters RSS

Remedy support for SQL Server Native Client

Andy Mitchell

Does Remedy 7.6.04 support SQL Server Native Client (SNAC) accessed through the ODBC interface when connecting to a SQL Server 2008 database?


I've looked in the document "Action Request System 7.6.04 Compatability and Support" however it doesn't reference which client drivers are supported when used with SQL Server. I believe there are some subtle differences between the Windows DAC versions (shipped with modern MS OSs) and SNAC which can break / cause undesired behaviour in some applications.



  • 1. Remedy support for SQL Server Native Client
    Keith Fawcett

    Did you receive an answer to this? We need to encrpyt data between the AR server and the DB.


    Did you receive any steps on how to set this up?

  • 2. Remedy support for SQL Server Native Client
    Misi Mladoniczky



    The AR Server does not use ODBC, so that should be no option.


    Why not set up a VPN-tunnel between the AR Server and the Database?


            Best Regards - Misi, RRR AB, http://rrr.se

  • 3. Remedy support for SQL Server Native Client
    Carl Wilson


    this might be one to bounce of to BMC Support.  BMC recommends that there are no network devices between the AR Server and the DB, therefore you "should" not need to encrypt the data.  They focus on the communications between the Client and the AR Servers with their available encryption packages as this is where the attacks usually occur, not from within:












  • 4. Remedy support for SQL Server Native Client
    Misi Mladoniczky



    That recommendation has to do with performance, right?


    If you have a single network cable between your physical AR Server and its DB, there is no opportunity for sniffing data, and you need no encryption.


            Best regards - Misi, RRR AB, http://rrr.se

  • 5. Re: Remedy support for SQL Server Native Client
    Carl Wilson


    indeed, but is still relevant in any setup although we all know in practise that hardly ever occurs.  The more performance degrading network devices between the Server and DB, the greater the delay.

    The recommendation is to have them as close as possible with no or little performance degrading network devices in-between i.e. Firewalls, routers, etc.


    That said, I have seen AR Servers and DB in geographically different countries causing massive performance issues.


    Doug has a great quote:


    11-Jun-2008 06:32 in response to: pseagers

    Re: AR System Database performance and network latency


    NEVER, NEVER, NEVER, NEVER (subtle enough) EVER put anything between the AR System and the database.

    There is no problem with putting the AR System and the database on different machines -- and in fact in server group environments and when there are heavy loads on the database it is often beneficial to put the database on a separate machine than the AR System server.

    However, it is critical that there is no firewall or ANY other block of any kind between the AR System server and the database.

    Yes, the type of degradation you describe is definitely seen when there is a firewall.  Remove that and you will find that the performance gets significantly better.

    The highest volume of traffic anywhere in the system is between the AR System and the database.  You need as fat a wire (as high volume) as possible with nothing to delay or interfere with traffic in any way.








  • 6. Re: Remedy support for SQL Server Native Client
    Keith Fawcett

    ODBC is installed on the AR Server in order to talk to MS SQL, correct?


    Per Microsoft:


    To encrypt all data transmitted between an application computer and a computer running an instance of SQL Server, SQL Server can use the Secure Sockets Layer (SSL). Before enabling SSL encryption, you must install a server certificate from a certification authority on the database computer, and the client must trust the same root certificate signing authority. For more information about SSL encryption, see Encrypting Connections to SQL Server.

    The Shared Memory protocol can only be used to communicate with processes running on the same computer as SQL Server. It is enabled by default. Windows manages the security of shared memory. Of the Microsoft client network protocols, this is the most secure.


    SOURCE: http://msdn.microsoft.com/en-us/library/ms190425.aspx


    In the Web Application Assessment and Vulnerability Mitigation Tests docuement, there is this section about the data layer.


    Data layer


    The Data layer consists of one or more databases, which perform data storage and retrieval functions. The AR System server connects to the Data layer using database client API libraries. The server can work with the database encryption libraries used to protect data that is transmitted between the server and database.

  • 7. Re: Remedy support for SQL Server Native Client
    Mark Walters

    ARS uses the native SQL client to talk to SQL server, it does NOT use ODBC.


    There is an encryption feature in the client that you can enable - see the link in the message above for details on how to configure this.


    However, please note that there's a bug in the MS SQL code that means you have to be using SQL Server Windows 2008 R2 (for the AR Server) for this to work with Remedy.



  • 8. Re: Remedy support for SQL Server Native Client
    Keith Fawcett

    Thanks Mark, just wanted to make sure it would work.

  • 9. Re: Remedy support for SQL Server Native Client
    Mark Walters

    A correction to my post - the AR server needs to be running on a Windows 2008 R2 system - earlier versions of the OS won't work due to a SQL client bug.