Ok, I've got a really weird issue. I've replicated this -- it's happened now on three separate, clean boxes.

Nutshell:
On a Windows 2012 box once you install VisualCron, if it's joined to the domain, a new profile folder appears in the C:\Users\ that's labeled with Chinese characters. If it's not joined to the domain, but then later joined to the domain, that folder appears when you do join the domain.

There is not a corresponding user on the machine, nor does one get created. That profile folder has the normal user folders in it, but is otherwise empty.

In all three cases, the Chinese in question was the same or similar. Twice it was: 汃敩瑮慄慴獕牥, and once 汃敩瑮慄慴獕牥鴀瀻߿ (notice it's like the other two plus two or three additional characters on the end).

This is really disturbing. Note we are in America, and we don't deal with any Chinese data in our business, in fact there's nothing we have that contains Chinese characters.

Thanks

Hi,

it does not sound likely that this is something created by VisualCron. First, we never seen this before in any installation. Secondly, we do not create any profiles at all. It sounds like another application.

What if you uninstall VC, delete the profile. Open the Users folder. Install VisualCron. Is it created then when viewing that folder?

---

We did some more testing -- it happens on restoration of the jobs.

We started with a totally clean Windows 2012 box, connected to the domain, and a fresh install of VC. We snapshotted it so we could roll back easily. On restoring the jobs into VC, it created the Chinese folder instantly. We then rolled back, and restored each component (Conditions, Notifications, etc.) individually, one by one. It did not create that folder until we restored the last component -- which were the jobs themselves.

We'll continue testing it next week to see if we can narrow it down to the specific job.

Thanks for the investigation - please let us know!

---

Ok, looks like the culprit is a file watcher trigger, using domain credentials that have local login and load profile checked.

We've replicated that with a new test job on a fresh box, so the import didn't have anything to do with the error.

Interestingly, it only seems to happen when the job trigger is created by another domain user. If local administrator is used to create it, the error doesn't happen.

Henrik, I was able to reproduce this.


1. New Server (2012 R2, in my case) No extra user folders in C:\User\
2. New install of VisualCron 7.1.5 latest beta
3. Enable AD authentication
4. Manage permissions, Creating a domain\User1 login with administrators as it's group
5. Log in with new User1 account (domain)
6. Create credential that is a domain user (domain\user2 for example) with load profile/local login.
7. Edit Job, add Event-->File trigger to watch another server: \\server\share for hello.txt, using the credential created in step 6, and save/exit the job.
8. Triggered the job by creating a hello.txt file in \\server\share

When I first tried, I set up a User2 credential, but I had already logged into the server via RDP as User2 and my profile folder got created. Nothing happened, as there was already a 'User2' folder in C:\Users\. You will only be able to reproduce this by creating a credential with load profile/login local, for an account that has no profile currently on the system. So if you look and there is no C:\Users\User3 and then go create a new credential for 'domain\user3' and apply it to a file trigger, immediately the chinese characters show up as a folder name in c:\Users\
It showed up as SOON as I saved the file trigger/job.

This is actually bad... Because now if I log into the server as User2, those chinese characters are actually my profile path and are not understood as valid. If I open a command prompt, it should default you to C:\Users\User2 as the current folder you're in. On mine it now says C:\Users\???\

I'm betting that the 'Load Profile' option likely needs to now have some sort of validation upon checking the box to ensure there 'is' a profile to load. Otherwise what's it going to load that would be beneficial anyway?

Brian

Thanks for the feedback and testing. Strange issue. What we have done in a new build is to check if the profile directory exist - if not, we do not load the profile. We would really appreciate if you could test this version:

http://www.visualcron.co....aspx?g=posts&t=3937 

---

Thanks for the feedback and testing. Strange issue. What we have done in a new build is to check if the profile directory exist - if not, we do not load the profile. We would really appreciate if you could test this version:

http://www.visualcron.co....aspx?g=posts&t=3937 

Out of Curiousity, how is the check for the profile being done? Are you doing a basic check in the C:\Users\ folder for a folder that matches (case insensitive) the userid or are you getting the SID of the domain account (if found) and validating the path noted in the 'ProfileImagePath' entry (location) exists under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-REST-OF-SID\

I only ask because on some systems, if something goes wrong with the profile or if there is a local account with the same name as a domain account, you might end up with 2 (or more) folders and the only way to ensure a particular folder is really the profile path is to validate the SID against the registry.

c:\Users\User2\
c:\Users\User2.DOMAIN\


Brian

Thanks for the feedback and testing. Strange issue. What we have done in a new build is to check if the profile directory exist - if not, we do not load the profile. We would really appreciate if you could test this version:

http://www.visualcron.co....aspx?g=posts&t=3937 

Out of Curiousity, how is the check for the profile being done? Are you doing a basic check in the C:\Users\ folder for a folder that matches (case insensitive) the userid or are you getting the SID of the domain account (if found) and validating the path noted in the 'ProfileImagePath' entry (location) exists under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-REST-OF-SID\

I only ask because on some systems, if something goes wrong with the profile or if there is a local account with the same name as a domain account, you might end up with 2 (or more) folders and the only way to ensure a particular folder is really the profile path is to validate the SID against the registry.

c:\Users\User2\
c:\Users\User2.DOMAIN\


Brian

First, let me clarify that we never create any profile folder ourselves. It seems the Windows API method LoadUserProfile do this when no one has logged on to the account.

To check the profile folder we call the Windows API method GetUserProfileDirectory. This method returns false if there is no profile directory.

But, as mentioned earlier it is interesting to see your tests in your AD environment to see if this works or not.

---

From what I can tell, the latest 7.1.5 Beta, Buil 27317 (assuming that's correct) does not appear to have the issue anymore.

That being said, I'm trying to think of a way to test a valid profile loading scenario.

Basically, I want to know that when I create a new credential... and the Profile doesn't exist yet, but the box is checked to load profile.... that if/when the profile DOES get created, that it begins actually using the profile.

Can you think of a valid way to test this? I created a new credential 'Domain\User2' and there was no profile currently. I set a file watching trigger to use that credential, and the trigger worked without creating a new profile folder (neither a User2 or one with chinese characters). So that's perfect.

However, now i'm trying to test that the profile is actually loaded. I'm confused, as maybe i'm not quite sure what 'loading profile' actually does. I logged into the system as User2, created a user-specific environment variable called 'vctest' and set it to "vc_variable". So from Powershell, logged in as User2, I can do this command, which should read the environment variable and write it to the screen/output where i'd see 'vc_variable'.


This works directly in powershell logged in as User2. So I logged out, rebooted the server, and then opened up VC. I created a powershell execute task that does this same command and tried running it without a credential (local system) and with the newly created credential that DOES now have a profile... and the variable isn't being returned. Maybe that's not a way to validate that the profile is loading, but i'm not sure how else to do something simple to validate. does 'Load Profile' not take into account User environment varaibles (not system) such as TMP and TEMP or any others created?

Brian

From what I can tell, the latest 7.1.5 Beta, Buil 27317 (assuming that's correct) does not appear to have the issue anymore.

That being said, I'm trying to think of a way to test a valid profile loading scenario.

Basically, I want to know that when I create a new credential... and the Profile doesn't exist yet, but the box is checked to load profile.... that if/when the profile DOES get created, that it begins actually using the profile.

Can you think of a valid way to test this? I created a new credential 'Domain\User2' and there was no profile currently. I set a file watching trigger to use that credential, and the trigger worked without creating a new profile folder (neither a User2 or one with chinese characters). So that's perfect.

However, now i'm trying to test that the profile is actually loaded. I'm confused, as maybe i'm not quite sure what 'loading profile' actually does. I logged into the system as User2, created a user-specific environment variable called 'vctest' and set it to "vc_variable". So from Powershell, logged in as User2, I can do this command, which should read the environment variable and write it to the screen/output where i'd see 'vc_variable'.

$env:vctest

This works directly in powershell logged in as User2. So I logged out, rebooted the server, and then opened up VC. I created a powershell execute task that does this same command and tried running it without a credential (local system) and with the newly created credential that DOES now have a profile... and the variable isn't being returned. Maybe that's not a way to validate that the profile is loading, but i'm not sure how else to do something simple to validate. does 'Load Profile' not take into account User environment varaibles (not system) such as TMP and TEMP or any others created?

Brian

I think the short answer is that it cannot be loaded unless it has been created fully (which is done when you log on the first time). Only way to create it without getting chinese characters is to first logon once on the desktop.

I am not sure about loading all environment Variables. But the best way would be to write the current user name to a file. Then you know the thread is running as that user. If Load profile is not working it will only get the permissions of that user - not actually run as that user.

---