User loosing settings every break

[Dmarin]

Hi Guys,

 

Hoping that some of you had/has this issue and solved it. It only happens for 2 users out of 250, but every break, if the user is not logging in for a week, when they get back, all the settings are lost. they have to create everything again.

We've checked everything we could think of, and we found nothing wrong with these 2 usernames. We changed the computer one of them uses, and the problem is still there, that made us think it's something at the user level.

Everytime they come back, windows treats the user like new to that computer.

I don't hope for a magical fix, but maybe some pointers? Deleting the username from that machine does not work, as we've changed the computer for one of the users, and all other users on that pc work fine.

In AD there is no difference, nothing weird about those 2 users. They were created a few month apart, so that is not something they have in common either.

Appreciate any input you might have on this.

Thanks.

[Olliedawg]

Run a gpresult as the user & look through policies.

 

Is there any evidence of Delprof (or something similar) on the network, which is affecting these 2 users

[bknaggs]

Sounds like something is running to delete profiles older than 7 days if it only affects them after being away for a week or more. When they login and everything has been reset does login take as long as a new user/someone who has never logged into that PC before?

 

A couple of things it could be are:

Group policy set to delete profiles older than x days applied to their PC

Del prof running as some form of scheduled task that only targets profiles older than x

 

In AD where are the PCs in relation to other PCs that users who don't have the problem use? Same question for the users.

[jthompson]

Do the affected users have unusually long names or unusual characters in their name?

Also, is there any AzureAD stuff involved, or is it all just on-prem AD?

[Davit2005]

What settings disappear? Do you have roaming profiles, mandatory or local? Redirected Appdata?

[Dmarin]

All of the above are checked. it appears to be random as both the computers and users are in OU's for the department they work in. Other users and comps are in there and they aren't affected. There is no GPO that deletes the users, or the whole 250 teachers will be deleted over summer. Delprof is not running, we rarely use it. And again all the other users would've been affected? it just seems so random

 

- - - Updated - - -

 

What settings disappear? Do you have roaming profiles, mandatory or local? Redirected Appdata?

The user settings, basically they become new user on those machines.

[Dmarin]

Do the affected users have unusually long names or unusual characters in their name?

Also, is there any AzureAD stuff involved, or is it all just on-prem AD?

 

No long names, we have way longer then them. We use a hybrid of local Ad and Azure Ad, with Salamander as a midway to SIMS. As the users are being created automatically from SIMS, i thought it might be something Salamander did when creating the users, a glitch or something, but they say that's not possible. Checked even the AD attributes fields compared to users that don't have the problem and found nothing odd.

We've even deleted the users and recreated them, and the issue is still there.

So yah.. happy days i guess.

[Davit2005]

Have you got a task to delete profiles anywhere that is misbehaving. I would not of thought this was an issue with the account created unless you have roaming profiles which is not working properly. Do you use roaming profiles or Mandatory profiles?

[jthompson]

Bit of a long shot suggestion this, but assuming you have Azure AD Connect running on-prem, it may be worth looking to see if there are any sync issues relating to those users. If you've deleted and recreated their local AD accounts, their corresponding Azure accounts might have the grump if GUIDs haven't been realigned as needed. Whether that would result in hybrid-joined computers treating signins in the way you've described, I don't know.

[Dmarin]

Bit of a long shot suggestion this, but assuming you have Azure AD Connect running on-prem, it may be worth looking to see if there are any sync issues relating to those users. If you've deleted and recreated their local AD accounts, their corresponding Azure accounts might have the grump if GUIDs haven't been realigned as needed. Whether that would result in hybrid-joined computers treating signins in the way you've described, I don't know.

 

Worth giving a try. Thanks for the suggestion.

[Dmarin]

Have you got a task to delete profiles anywhere that is misbehaving. I would not of thought this was an issue with the account created unless you have roaming profiles which is not working properly. Do you use roaming profiles or Mandatory profiles?

 

Mandatory. The only way i can think errors are being generated, it's the sync between SIMS and Azure Ad that happens through Salamander. And they always are prompt to help, but this time they don't know what the issue might be. So i guess we'll have to learn how to live with this.

Thanks.

[network41]

Similar -ish issue here. One user affected. Every morning he have to go into his AD account and reinput the groups he should be a member of. Only thing that runs overnight that I think it is . is the Salander sync. They are looking in to this for us.

[Dmarin]

Similar -ish issue here. One user affected. Every morning he have to go into his AD account and reinput the groups he should be a member of. Only thing that runs overnight that I think it is . is the Salander sync. They are looking in to this for us.

 

If they find a fix for it, please do share, it might as well be a similar thing to ours. Although yours seem a bit more acute, as it happens every night. Is that user set up correctly in SIMS?