dflansy
Visitor.
1287 views

Windows 10 issues with OES client

I am having issues with windows 10 1803 trying to log on the last user. I have done a lot of reading on automatic restart sign on. I have updated the client to IR10 and verified the registry value to disable ARSO is present. However, it will still bring up a local login for the last user, occasionally. It seems that the registry value helps but doesn't cure it. Is anyone else having this issue or know of a more permanent fix? Thanks
Labels (1)
Tags (2)
0 Likes
5 Replies
Micro Focus Contributor
Micro Focus Contributor

Re: Windows 10 issues with OES client

dflansy <dflansy@no-mx.forums.microfocus.com> wrote:

> I am having issues with windows 10 1803 trying to log on the last user.
> I have done a lot of reading on automatic restart sign on. I have
> updated the client to IR10 and verified the registry value to disable
> ARSO is present. However, it will still bring up a local login for the
> last user, occasionally. It seems that the registry value helps but
> doesn't cure it. Is anyone else having this issue or know of a more
> permanent fix? Thanks


We are actually seeing reports of this as well, in addition to random
instances that occur but won't duplicate on lab machines. It seems as
though even with the policy in place, the ARSO behavior is still able
to occur in "random" instances. This is still under investigation,
but if you had Microsoft support services available, contacting them
regarding the ARSO policy not being effective can be appropriate too.

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com
0 Likes
dflansy
Visitor.

Re: Windows 10 issues with OES client

Are there any updates in your investigation on the issue? I tried asking on the Microsoft forums with no luck.
0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: Windows 10 issues with OES client

dflansy <dflansy@no-mx.forums.microfocus.com> wrote:

> Are there any updates in your investigation on the issue? I tried asking
> on the Microsoft forums with no luck.


Still looking for a method to reliably detect the ARSO logons when
they occur. That's what was originally not deemed to have a clearly
reliable approach, and setting the ARSO policy was the better option.
The case with Microsoft hasn't been opened yet, so no information
directly regarding what might be intentional or unintentional about
the ASRO policy being "set, but not honored."

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com
0 Likes
mdymes Absent Member.
Absent Member.

Re: Windows 10 issues with OES client

I am also having a rampant problem with this. Funny thing is, I cannot forcibly get a computer to have this behavior, but computers are 100% doing this within the organization.

Windows 10 build 1709
Zenworks 2017 latest build
OES Client / mix of last 2 builds

Windows GPO set to disable ARSO and User fast switching. Really looking for some strategy to overcome this.
0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: Windows 10 issues with OES client

mdymes <mdymes@no-mx.forums.microfocus.com> wrote:

> Windows GPO set to disable ARSO and User fast switching. Really looking
> for some strategy to overcome this.


We're still working with Microsoft on this issue, but don't seem to
have identified what the true root cause or solution will be.

For the one (1) case where a Process Monitor log of the issue could be
successfully captured, it was determined that the Microsoft GPSVC
(Group Policy Service) was "deleting and then immediately re-creating"
the local registry policy value.

Meaning the "disable ARSO" policy was correctly set prior to
rebooting, but /during/ the actual boot, the GPSVC service deleted and
re-created the policy. And the Process Monitor log showed that the
LSASS process refreshed it's view of "is the ARSO disable policy set"
during that moment when the policy no longer existed in the registry.
Despite the fact that the policy was then re-created moments later.

i.e. Right at the moment the ARSO logon was occurring, the policy
didn't exist in the registry. Even though it did exist in the
registry immediately before, and immediately after.

We've been trying and unable to duplicate this issue "on demand" for
further study. We feel like we've seen evidence of it occurring even
on stand-alone workstations without group policies applied, but have
yet to truly "prove" that. Microsoft is currently looking at the one
(1) Process Monitor log that was collected, but its understandably
difficult to get good investigation traction with such scant evidence.

The strategies for trying to "detect" or "react" to presence of an
unwanted ARSO logon are a bit brittle and unreliable, but we're
continuing to look at that approach as well. In case the ability to
resolve "why hasn't the disable ARSO logon policy not 100% disabled
ARSO logons" through Microsoft doesn't end satisfactorily.

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.