From: Michael Chung-Haas School of Business Michael Chung-Haas School of on
I've been having this problem for quite a while now as well (ever since we
deployed Terminal Services 2008 in our org).

I think I just fixed it....not sure if this will work for you guys, but give
it a try and I'd be curious to know your results.

Here's what I did:
We deploy TS Session Broker settings thru GPO, so I opened the GPO policy
that contained session broker information.

I went in and changed the name of the session broker server to a NON-FQDN.
Previously, server was set to: "tsserver.x.y.z"
I changed it to: "tsserver"

Refreshed policy, and the 1014 error went away!

The reason I started messing around with FQDN vs. non-FQDN is because our
environment is NOT using DDNS (yeah, long story), and the FQDN of our AD
environment does NOT match domain used for DNS.

For example, FQDN of the AD host might be: server.addomain.root.edu, but
entries used for DNS name resolution of servers might be: server.root.edu.
Obviously this goes against Microsoft best-practices, but like I said, it's a
long story.

I had also tried specifying the FQDN of the AD host name in the GPO as
Session Broker server. This also required me to put an entry in each
Terminal Server's HOSTS file since our DNS servers do not resolve the AD
domain names. That did not work, which lead me to simply try the non-FQDN.

I'm curious if those of you having this problem are also operating in a non
DDNS environment. This has been known to cause problems with other
Microsoft services (ie: SCOM).

Michael Chung

"Thorsten" wrote:

> I started to get the absolute same error about a few weeks ago.
>
> My configuration isn't very complex, just two terminal servers load balanced
> by a single session broker that is TS licensing server at the same time.
> However, neither of the servers was installed using a image.
>
> One of our servers (the one producing the above mentioned error) denies
> logons now (a user can type in his creds and hit logon, the server then goes
> on presenting the "Welcome" screen but closes the session afterwards).
> As soon as i remove this server from the session broker farm, logons work
> correctly.
>
> I already checked DNS lookups and network connectivity of all three servers
> but can't find any issues. In addition the other terminal server seems to act
> normally although member of the session broker farm.
>
> Greets
> Thorsten
>
> "Ole Thomsen" wrote:
>
> > I see the Session Broker SID error multiple times every day on all servers
> > in our farm, and sessions are distributed fine.
> >
> > Don't think that is the reason for your problem.
> >
> > Ole Thomsen
> >
> >
> > "Kristin L. Griffin" <KristinLGriffin(a)discussions.microsoft.com> wrote in
> > message news:13DE6307-C7A9-4381-B7F5-4577BE6584E4(a)microsoft.com...
> > > Hi Folks,
> > >
> > > I have a weird issue.
> > > Even through the session broker server says my terminal servers joined ok,
> > > the terminal server system logs say differently. I get this message:
> > >
> > > The server failed to retrieve the security identifier (SID) of the TS
> > > Session Broker server.
> > > Win32 error code: 0x534.
> > >
> > > All terminal services connections go to only one server - they are not
> > > dispersed.
> > >
> > > Here are some network details and things I have ruled out:
> > >
> > > This is a Win2k8 environment.
> > > I have a farm of terminal servers (obviously)
> > > This is a completely virtual server environment, using HyperV
> > > I am not having network, dhcp, dns issues. Everything is running fine in
> > > that respect.
> > >
> > > I have:
> > > Gotten rid of NLB and went back to round robin DNS
> > > reinstalled session broker
> > > rebooted all machines
> > > cleared dns cache on all machines
> > > checked pings and connectivity to each machine
> > > ruled out network firewall by removing it (even thoug
> > > no firewall is turned on on any servers.
> > >
> > > TS Team, any ideas here?
> > >
> > > Thanks,
> > >
> > > Kristin
> > >
> >