SOLVED

Cannot login to Surface Hub

Copper Contributor

We have on-prem a Surface Hub configured which was working perfeclty up to a few days ago.

For some reason, it cannot login anymore to the calendar and mail account associated with it.

When trying to go to settings to vaerify connectivity, and after introducing the admin login (which is correct, as it is the same login I use to log on to the domain), it gives the message:

 

"The security database on the server does not have a computer account for the workstation trust reltionship".

 

I chjecked on the Domain Contreoller, and there were no changes on the account, besides the password reset automatically done by the device.

 

Can anyone help?

 

Thanks.

8 Replies
best response confirmed by Gonçalo Oliveira (Copper Contributor)
Solution
this sounds like the device has either rolled-back or system-restore/recovery has occurred, or, an AD admin has 'reset' the computer account password on the domain controller side.
effectively, the device can no longer authenticate to the domain using the secure-channel-password previously negotiated. the device is presenting an invalid password (according to the domain). this can happen to any device attempting to bind (logon), just as it can happen for a user account/password.

to recover, you will need a local admin identity. if you didn't set one of those up, when you unboxed the SHub (eg you only nominated a domain group for device admin), I think you will need to reset/recover/reimage the SHub and perform OOBE all over again, rejoin the domain etc. the trick, is that you will need to be authenticated as admin to initiate reset/recovery/reimage, AFAIK.
Please check in settings that you have the account setup correctly and it is synched.

Is it possible the domain account password has expired and requires changing?  You can verify this by logging into Office365 or any domain joined workstation with the hub username and password and see if you have the same behavior.  If thats the case, have the admin set the password to never expire. 

Hi, Don.

The issue, I believe, is related to changing the password on the Domain Controller, and not having set a local admin account (or at least loosing that access on my records).

I do believe the only way to recover the device is, as you mentioned, restore from factory image, which was something I was trying to avoid, even being a smooth and relatively fast process.

The recovery process can be bypassed by using the power switch in a very specific way (did it once), so you don't really need access to device settings.

The power switch trick, I'm familiar with, that forces Windows into Automated System Recovery (ASR). I did that once, and bricked the SSD. I'm not a fan :(
Although I've been working with Windows for 20 years, I feel a little constrained by this implementation on SHub, I haven't (yet) found a way to dig deeper using my traditional techniques (which have been very effective in enterprise scenarios for a long time) [old dog, needs new tricks] :)

I found on the documentation of the product that we can only have 1 out of 3 forms of administration accounts: local, AD account, Azure AD account. They are mutually exclusive, and the type of authentication is one of the steps of the first time configuration wizard, although it can be changed later using settings (for what you need to have the permissions).

So the only way to recover the device was performing a factory reset using the power switch trick.

Thanks for all your comments and support.

Hi Goncalo

While I'm really glad to hear you've resolved it through device reset, I'm still intrigued by how this happened.

Given the fact it was joined to on-prem AD, a change of the device account password will not affect the trust relationship between the Surface Hub and the domain controller (we reset the device account passwords all the time for various troubleshooting/testing reasons). Likewise, users that were part of the AD group you specified during OOBE should have still been able to authenticate into the device settings (providing they had already signed in at least once as the Surface Hub will cache the credentials... have tested this with a Surface Hub disconnected from the network).

This sounds more like either someone (accidentally) either deleted the computer object in AD, (thus breaking the trust relationship), or it's one of those unfortunately oddities where a seemingly perfectly good computer just stops trusting the domain it's joined to (or vice versa).

Unfortunately with Surface Hub, the only way to bind to a domain is during OOBE, so the moment the trust relationship was broken the ONLY option would have been to do a device reset.

Either way, as said previously, I'm glad to see you've now fixed it :)

Also, for those wondering on the power switch 'trick', the point you need to flick the switch off is during boot at the black screen with the grey Windows logo. It will start saying 'Please Wait' then change to 'Welcome' before booting into the Welcome Screen. It's when it says 'Welcome' you need to switch it off. Do this three times in a row and it should boot into the recovery menu.

You can find out more here (https://docs.microsoft.com/en-gb/surface-hub/device-reset-surface-hub). Unfortunately as they refer to the black 'welcome' screen as the 'welcome screen' in the admin guide, it's not particularly clear. I may grab a screenshot from one of my setup captures and update the article myself shortly to make it clearer.

Hi, Daniel.

I don't really know why the device lost the AD trust. I know that sometimes happens on Windows machines by no special reason. And the device had my admin credentials cached, as I configured the device using the same credntials.

Anyway, the issue was fixed, and the internal SSD survided to the power switch trick :)

 

1 best response

Accepted Solutions
best response confirmed by Gonçalo Oliveira (Copper Contributor)
Solution
this sounds like the device has either rolled-back or system-restore/recovery has occurred, or, an AD admin has 'reset' the computer account password on the domain controller side.
effectively, the device can no longer authenticate to the domain using the secure-channel-password previously negotiated. the device is presenting an invalid password (according to the domain). this can happen to any device attempting to bind (logon), just as it can happen for a user account/password.

to recover, you will need a local admin identity. if you didn't set one of those up, when you unboxed the SHub (eg you only nominated a domain group for device admin), I think you will need to reset/recover/reimage the SHub and perform OOBE all over again, rejoin the domain etc. the trick, is that you will need to be authenticated as admin to initiate reset/recovery/reimage, AFAIK.

View solution in original post