locked
Appv Client NTLM problems RRS feed

  • Question

  • Hello,

    When I attempt to perform a refresh using the AppV Client I get the following error:

    The server will not allow a connection without valid NTLM credentials Please report the following error code to your System Administrator.

    I found a MS KB article that simply says:

    "You may get this with local domain accounts as well as if using another trusted domain account."

     

    1. My AppV backend is running on a Windows 2008 R2 x64 server
    2. My AppV Client is running on Windows 7
    3. Both client and server are in the same domain

    I am not sure where to go from here, any suggestions?

     

    Thanks,

    Robert

     

     

    Friday, May 14, 2010 6:58 PM

Answers

All replies

  • Hello,

    are you logged on with an user account from the domain?

    /Znack
    Friday, May 14, 2010 9:49 PM
  • We're experiencing the same issue, but with AppV client for terminal servers. You have'nt said anything about which client / server version you're running, but if its 4.6 both client and server, then the http://support.microsoft.com/?kbid=930721 is not applicable. (if I've understood it correctly)

    I've troubleshooted this exact problem for a week now, testing every solution there is to no avail. What's interesting dough, is that our old client (v.4.1.0.56) is working fine. That is with the applications sequensed with the old sequenser :)

    To sum up our solution in a couple of words:

    * Backend App-V  v.4.6 server on Windows Server 2008 R2 x64
    * Database resides on a SQL Clustered solution (off-box)
        - Because of this we've changed the Application Virtualization Management Server to run under a domain user account with the following privileges:
            * Local Admin on the App-V backend server 
            * DBO on the database (no priveleges on the actual SQL Server although we've tested that also)
            * Read / Write Priveleges on the Content area which resides on a clustered fileserver
    * App-V Client for RDC / Terminal Servers v. 4.6

    As you stated, our solution resides in the same domain exept for the SQL Server and there fore also the Run As Account also. This may of course be the case for us, that is the user running the streaming service is in another domain than the actual app-v server and client.

    What's bugging me, is that the old client is working as a charm. This should in most cases mean a misconfiguration on the client side, but it could also mean that the architecture on the new client have changed.
    I even tried reinstalling both the client and server several times, looking at the Microsoft documentation for guidance. The same output is presented every time.

    So you asked, where to start? This depends on your configuration / architecture. If you're running a simillar environment as we do, exept for the cross-domain thingy, I would suggest that you start with http://support.microsoft.com/?kbid=930721 and testing the connectibility from the backend server. If everything works out there (be aware of network devices in between with RTSP handling), I would turn my eye to the streaming service on your backend server. Is it running under the right credentials? Remember it should have priveleges on both the backend server, database and content area. I have seen posts regarding the user running the streaming service, and that some have come around this issue by running it under the Local System account. I guess that is plausable if you're running both the SQL and Content area locally, but for us that did'nt work out.

    I've also had a go at the client by changing the "Require User Auth. even when cached", which was a long shot and which obviously didnt work. I also tried changing the Providor policy on the backend server to not Authenticate, but that one did not change the behavior either...

    So, I would say that I'm running out of options and are'nt that far from calling Microsoft my self for roundup...

    Anyone have something to add?

    Wednesday, May 19, 2010 2:47 PM
  • Hello,

    Since it complains about NTLM-credentials, is that used throughout the environment? I have only seen the problem in mixed scenarios....

    /Znack
    Thursday, May 20, 2010 5:02 AM
  • I'm not sure what you're getting at here, but I think the issue here is related to the fact that our SQL server is in another domain (yet trusted domain) and that the authentication data from my user is'nt forwarded correctly. I'm not sure how this hangs together, but I've seen articles refering to the use of SPN's when changing the Application Virt. Management Server to run under domain user credentials insted of Network Service. So, now I've changed the SPN to the domain user running the serivice and removed the accordingly SPN on the domain computer hosting the App-V service.

    o        SETSPN –A MSSQLSVC/<SQL Server: Port Number> <SQL Server Service Domain Account>
    o        SETSPN –A MSSQLSVC/<FQDN of SQL Server: Port Number> <SQL Server Service Domain Account>
    (http://social.technet.microsoft.com/Forums/en/appvbeta/thread/397e99e9-46b4-449f-af6b-76568ec9a2fe)

    This made the original error to dissappear, but now I'm facing a new one (of course):

     ---------------------------
    Application Virtualization Error
    ---------------------------
    The Application Virtualization Client could not update publishing information from the server Softgrid.

    The server could not authorize you to access the requested data. Report the following error code to your System Administrator.

    Error code: 4604EE8-16906404-00000917

    ---------------------------

    The authorization issue I think is related to kerberos and cross-domain authorization. So... I thought that maybe this was due to the fact that the user running the App-V service do not have the right to Delegate. Unfortunately, giving it delegation rights only apply in the mother domain and not the trusted domain.

    Am I totally off on this one?

    Microsoft has an article for this error code, but that one doesnt give much, as my user already have the correct priveleges to the default provider policy...
    http://support.microsoft.com/kb/939327

    I'm really at a dead end here now and are considering reinstalling (again), but this time in the domain which the SQL server resides. This would potentially solve my authentication issues, but will it bring other problems with it?

    Thursday, May 20, 2010 1:21 PM
  • Hello,

    Since it complains about NTLM-credentials, is that used throughout the environment? I have only seen the problem in mixed scenarios....

    /Znack


    In fact, I think I have my answer here:

    http://blogs.technet.com/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

    And reading that App-V 4.5< only use Kerberos / SSPI for authentication / authorization, we need to have a look at the domain trust (or just install it in the same domain as the SQL server :))

    Please feel free to submit any thoughts on this one, as I'm struggling to dig my self out of the ditch I'm in :)

    Thursday, May 20, 2010 2:10 PM
  • I am logged on to the domian, and we do not use any cross domains.

     

    More on configuration:

     

    Backend

    • Windows 2008 R2 Enterprise x64
    • Management Server 4.5 SP1

    Client

    • Windows 7 32 bit
    • Desktop Client 4.6
    Thursday, May 27, 2010 7:52 PM
  • I installed the client on the backend server itself, and I am still getting the NTLM error.

    Thursday, May 27, 2010 7:53 PM
    • Proposed as answer by znack Wednesday, September 28, 2011 7:56 PM
    • Marked as answer by Aaron.ParkerModerator Friday, January 13, 2012 5:42 PM
    Monday, September 26, 2011 5:27 PM