Archive for July, 2011


http://blogs.technet.com/b/isablog/archive/2010/08/02/new-in-forefront-tmg-sp1-redirect-on-deny-with-dynamic-parameters.aspx

http://blogs.technet.com/b/isablog/archive/2009/11/26/deny-page-customization-on-forefront-tmg-2010.aspx

This little error could be solved by one of the 2 methods

1- On windows 2003 use  C:\WINDOWS\system32> lodctr /R

2- On Windows 2008,R2 Make sure that the drive you are storing the DBs on is not compressed

I was faced today with the issue when trying to create an ODBC connection from an Application server to the SQL server.

When using Windows Authentication to access the SQL I got an error of “sql Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.”

Looking at the Application log I got the below

“SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure”

Now snooping around google I can see that this is caused by various reasons

1- Incorrect SPNs registered to the SQL Server

So performing SETPSPN – L Servername

image

Which looked fine to me, but if it doesn’t in your case delete the MSSQLSVC SPNs and restart SQL services and it should get re-registered automatically.

I returned to the Application Log on the SQL and now I could see the following

“Login failed. The login is from an untrusted domain and cannot be used with Windows authentication”

I verified that the FQDN of the Machines is infact the expected as others reported that this could be an issue

image

Now continuing to look for issues, I found this article http://www.microsoft.com/products/ee/transform.aspx?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=18452

As it suggests at the end

  • Check your local security policies to see if any essential rights have been denied.
  • Try to connect to a share on the server. If connecting to a share fails, the account may not have "access this computer from the network" rights or may be missing other domain or network level permissions.”
  •  

    I tried to make a network share access to verify the connectivity between machines and I was UNABLE to do that.

    Running an RSOP (Resultant Set of Policies) report showed that the “Access From network” Setting was locked out to a single user.

    So I removed it and refreshed the GP and now I can access the share.

    So going again to the ODBC, and it Worked perfectly fine.

    Hope this helps out.

    Well today we faced an issue with a Third Party app that runs off a shared folder off the APP server

    When the app is run it errors out with a code 0x80070721 we get from the LOG while doing an operation of CreateObject

    Looking around I came to know that this means a “Security Service Package Error”

    So I ran Microsoft Network Monitor and I saw the following

    KerberosV5 KerberosV5:TGS Request Realm: <domain.local> Sname:  svc_PWDSRVR

    This is definitely a Kerberos error, so looking at the SPN registered on the APP server, I found none referencing the Service Account we need

    so I ran the

    setspn -A DCOMService/DCOMServerDomain COMServiceAccount
    setspn -A DCOMService/DCOMServerFQDN domain DCOMServiceAccount

    Now the DCOMService is the name of the DCOM app on the server in my case it was PWDSRVR

    The DCOMServerDomain is the NETBIOS Name of the Server where the DCOM APP resides. and DCOMServerFQDN is the FQDN of it.

    The DCOMServiceAccount is the Service account under which the DCOM runs. it is what you get from the Sname on the network monitor.

    so I did

    SETSPN –A PWDSRVR/MyDCOMServernetbios svc_PWDSRVR

    and

    SETSPN –A PWDSRVR/MyDCOMServernetfqdn svc_PWDSRVR

     

    it works like a charm Smile.

    Well I was banging my head for that error that seemed to affect some of the PCs in a client’s location

    clip_image001

     

    Looking at the WindowsUpdate Log locates in the %windir%\WindowsUpdate.log

    I could see this

    clip_image001[5]

    A little bit of googlin suggested that firewall is the issue as it is blocking HTTP Redirection and Cookies

    We go through a Juniper SRX to the internet

    so I thought of setting the IE Proxy to the ISP proxy like below

    clip_image001[7]

    Surely after that I went back hit the update and voila it works

    clip_image001[9]

    So looking at the SRX we allowed direct access to internet from the WSUS and then everything flowed smoothly.

     

    hope this could help someone or at least point him/her to the right direction.