Temporary Profile Problems with Active Directory to Blame

I recently received a ticket from my helpdesk escalating to my team.  It reported that two relatively new users were unable to get local user profiles on two computers.  They were receiving errors that a profile could not be created and a temporary profile was used.  

The full language of the error is: "You have been logged on with a temporary profile. You cannot access your files and files created in this profile will be deleted when you log off. To fix this, log off and try logging on later. Please see the event log for details or contact your system administrator."

The helpdesk staffer asked me to "delete or correct their AD profiles."  What?  I am certainly not deleting a user's Active Directory account.  I took the ticket, determined to demonstrate to the helpdesk that the problem was with these two computers and had nothing to do with Active Directory.

Sadly, that was not the case, oops!

My expectation was that the Default User profile on these computers was damaged, so new profiles were not being generated successfully.  I disproved that theory when I logged onto the system for the first time.  It generated a local profile for me without error or issue.  Hmmm.

At this point, I indeed had to go into Active Directory Users and Computers and I examined the two user accounts in question.  A little review, and the problem quickly came to light.  

Somehow, some info had been typed into the "Profile path" field.  We don't use roaming profiles, so this field should be left empty/default.  I typically copy user accounts (to preserve a number of account settings like group memberships for a similar job title), so I had copied this problem around to these two new users.  I also found this problem on the source user account.

By deleting the text from the Profile path field, the users confirmed their next logons were without issue.  They managed to create local profiles without error.

A simple problem, but it stumped me for a few moments, so it seemed worth sharing.

False Positive Malwarebytes mdm.exe

On September 13, 2016, I discovered approximately 100 emails from my Malwarebytes Management Console, where I run Malwarebytes Anti-Malware and Anti-Exploit for my end users.  

They were entries such as the following:

9/13/2016 11:15:22 AM <client> <ip> Ransom.Petya Quarantined C:\Program Files (x86)\Common Files\microsoft shared\VS7DEBUG\mdm.exe

or

9/13/2016 10:40:22 AM <client> <ip> Ransom.Petya delete-on-reboot C:\Program Files (x86)\Common Files\microsoft shared\VS7DEBUG\mdm.exe

9/13/2016 10:40:22 AM <client> <ip> Ransom.Petya Quarantined HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\MDM

The entries began at 6:53AM ET and ended at 11:15am ET.

The volume and location within seemingly legitimate operating system locations made me think I had a false positive on my hands.  Some research promptly confirmed that.

By good fortune, one response already identified the resolution from Malwarebytes support.

https://community.spiceworks.com/topic/1823976-ransomware-or-false-positive

Log onto the Malwarebytes Management Console

Click the Client Pane

Select the computer affected from the list of clients

Click the Security Logs Tab along the bottom

Right click the item you wish to restore, then click either: 

Restore this Object... to restore to the computer selected

Restore this object on all clients... to restore this item to all clients

Whew!  I was able to restore the object on all impacted systems with a few quick clicks from the console.  What a relief!  

As an aside, I was not overly familiar with mdm.exe.  It is apparently the Machine Debug Manager.  So it probably wouldn't affect end users terribly, but would thwart people in IT trying to do any troubleshooting on a system potentially.

I'll update this post with any fallout or any further issues.  I wanted to get it up quickly in case anyone else was similarly impacted and panicked like I was.

P.S. Please be careful with reports of viruses in mdm.exe.  It is apparently a known problem, but typically the file is not in its default location I outlined above.  

UPDATE 9/16/2016:
We had a SECOND round of this occur 9/15/2016 from 2:42pm ET to 4:31pm.  I called support myself shortly after 4pm (on the first go-round, above, I relied on the experience in that link provided).  

Support confirmed unofficially that it was a false positive, and collected data from me.  At 5:03pm they let me know it would be fixed in the next update.  

I connected remotely during the off hours,  I saw my definition time stamp had moved from 4:xxpm to 9:xxpm, so I again did the Restore this object on all clients and hopefully can put this to bed.

Concerning DLLs in the root of C drive; spyware infection? No

At work, I upgraded my laptop by replacing the hard drive with an SSD.  Boy, did it make a nice improvement in performance.  I took the purist approach and did a fresh install of Windows 7 and reinstalled all my applications.

Imagine my chagrin after a careful rebuild, only to find a number of DLL files in the root of my C drive.  I deleted them, only to find them returning regularly.

Doing some Googling on one of the DLL names (such as tsgetxu6ag55.dll) wasn't turning up good results.  I'd find lots of results to web sites that 'identify files' and would give me a lot of nonsense answers not clearly telling me if it was spyware, a legitimate file, or any useful info.

I stumbled onto what was going on once I started Googling what the file was.  The properties of the DLL made mention of Tom Sawyer.  Once I Googled that, lo and behold the answer came to light.

https://thwack.solarwinds.com/thread/55808

One piece of software I had reinstalled was SolarWinds IP Address Tracker.  The newer version apparently isn't well-written, and it dumps many files in the root of your C drive.  Well, that's helpful (NOT).

At that point, I searched and found an older version of the install and downloaded that.  No more pesky DLLs appearing in the root of my C drive.