Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 374
  • Last Modified:

User Profile troubleshooting

I am troubleshooting an issue with user profiles and run into a wall... Basically we have 2 terminal services environments both uing the same Domain and the same applications. The application when working as intended, created a copy of an .ini file on the users profile Windows folder on the terminal server, however, of the 2 environments, one works as intended and the other doesn't and I am not sure how to troubleshoot this. As far as I can think, they were both installed the same way but when connecting to the terminal server on one of this environments, the .ini file gets created but when connecting to the other environment (Server Farm) the .ini doesn't get created.

Can someone provide some insight as to how to troublesoot this typeof problem?
The Windows directory gets created but no .ini file is placed in it. If we manually copy it to a user's profile, it still doesn't use that file and will use the one on the main Windows directory.

Thanks
0
troubleshooter141
Asked:
troubleshooter141
  • 7
  • 5
3 Solutions
 
Davis McCarnOwnerCommented:
Log into each as a user and type SET<enter> in a CMD window.  Inspect the path and environment varibles for differences.
Check the permissions for users on the created directory for differences.
Does that INI file exist in the Windows folder on the server that works?
0
 
Sarang TinguriaSr EngineerCommented:
Its quite difficult to understand the questions can you give some more details ...
0
 
troubleshooter141Author Commented:
DavisMcCarn

Yes the ini filesdoes exist on the user's profile windows folder on the server that works correctly. I tried comparing the outpout of the set command and everything looks good to me, te only differences I have seen were with th TCP field which I attributed to the interface being used.Everything else seems to match including the path.

I took it a step further and uninstalld te application, opened a command line as administrator and changed uer to /install just in case I had forgotten to do this the when Iinitially installed it. Once completed I changed user to /execute and tested but still unsuccessfull.
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
troubleshooter141Author Commented:
sarang_tinguria

I'll try to clarify:

We have an inhouse written application which creates an ini file on the Windows directory during the install. When used in a terminal services environment, the ini file gets copied to each user's profile windows directory the first time the user logs on to the server. That beind said, We have two server farms and this works correctly on one but not the other. The ini file on the farm that is nt working correctlydoes not get copied to the user's profile and the one under c:\Windows gets used instead. The problem with this is that there areseveral things on that file specific to each user and when they share that file like it is happening now, their settings are getting mixed up.
0
 
Davis McCarnOwnerCommented:
You said earlier that, on the system which doesn't work, users get the C:\Windows\<whatever>.ini
On the server which works, is there a C:\Windows\<whatever>.INI file?
If there isn't, what happens if you rename or delete it?
0
 
troubleshooter141Author Commented:
Both servers have C:\Windows\myprogram.ini. This gets done during the program installation. On the system tat works users get C:\Users\myuser\windows\myprogram.ini but on the system that doesn't work this is not happening and users are using the c:\windows\myprogram.ini that is created during the program install and sharing it which is the problem.

I just double checked the executabl for th eapplication to make sure the TSaware is set to no and that is the case on both working and not working systems which if I understand correctly would force it to use shadow keys.
0
 
Davis McCarnOwnerCommented:
1) Are there events listed about access denied?
2) Check the permissions on the C:\Users\myuser\windows\ folder to see if they are different.
0
 
troubleshooter141Author Commented:
Not thatI can tell ( i made sure users have full rights to the .ini file nd also run process monitor while connecting to see if any access denied messages were being logged)


C:\Users\myuser\Windows\  permissions are set to full rights for the user on their windows folder. This is the case on both of the servers.

I reinstalled the server on Friday but the results are the same:
Formatted Hard Drive
Installed Windows 2008 R2 and installed all updates
Installed kb2726399 to address Display issues on Remote Desktop services
Change user /install
Installed application
Change user /execute

Tested unsuccessfully. The Windows directory on the users' profile is created but the .ini file is not being copied to it. If I manually copy it it still reads from the master .ini file in c:\windows
0
 
Davis McCarnOwnerCommented:
Is there a login script on the server that works which is not on (or not working on) the one which doesn't?
I ask because the normal search path for any file is the current folder first (usually where the program launches), followed by the folders listed in the PATH section of the environment variables which is displayed using the SET command.
On my machine, for example, that line starts Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem and any program I launch will look in Windows before it ever tries C:\Users\myuser\windows\ , using the first one it finds.
You either have two versions of the program, it is failing to install properly on the second server, or another process (login script) is creating that INI file and changing the path values.
0
 
troubleshooter141Author Commented:
I did a new reinstall today but chaged the order in which I installed things and it worked when I first reinstalled Windows and the application. After Windows updates it quit working.... I am now comparing all the updates to figure out which one might have caused this issue.


I do appreciate your input, this has been a very frustrating troubleshooting process but I think I am finally making some progress.

Thanks again
0
 
Davis McCarnOwnerCommented:
Is the other server not getting updates?  That is really dangerous, these days!
0
 
troubleshooter141Author Commented:
So after more testing I figuredout I was wrong and this wasn't caused by a Windows update. If I install Windows 2008 R2 and add the Remote esktop role and then install the application, I can RDP to the server and use the .ini file from my user's profile. Once Iinstall the 2X Application Server Agent, and launch my application, a registry key is created under:
HKEY_Local_Machine\Software\Wow6432node\Microsoft\Windows T\CurrentVersion\Terminal Server\Compatibilty\Applications for my application witha flag of 0x00000408 (1032). Once that key is created, I remote sessions go back to using the ini file from c:\windows but if I delete it I use the key from my user'sprofile. I tried deleting it however it gets recreated after a while. I also tried changing the flag to 0x00000080 and it works for a while but then something changes it back.... Any ideas onhow I cna keep the flag frm being changed or recreated?

Thanks
0
 
troubleshooter141Author Commented:
not resolved but no longer a project I am working on
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now