Hi APK,
 
Thanks for the rapid response, I know GINA can be a bit of a pain (past experience) so am petrified going anywhere near that!!
 
I'll take a look at the other options you have given and let you know,
 
Thanks again
 
Tricky_Luck

If the machine is a domain controller then there are NO local accounts.
 
You can log on using the Administrator account and the password defined prior to promoting to a DC if you boot into Directory Services Repair mode.
 
Otherwise, why do you need exclusive local access to the server? Is a user that's a member of the Administrators/Domain Admins not sufficient? Do you have GPOs set to break some Administrative privliges?
 
You can use the free Microsoft Group Policy Management Console to quickly and easily your RSOP or effective permissions applied from your GPOs.

Hi Adam,
 
The reason for this request is that we are trying to get ACT working on a Windows 2000 Server
 
1) ACT is not officially supported in a Terminal Services environment but we have other customers using it fine.
 
2) The version of ACT was installed fine until we tried to run Write (ACT's Word Processor) which bought up security errors
 
3) Our ACT Guru said that this was because in a Terminal Services environment it needs to be installed as the LOCAL Administrator to make sure all the users get the right permissions.
 
4) I presume that this is why ACT recommend putting their software on a different server altogether.
 
I know that this is related to Terminal Service and ACT and should be in the applications section but I didn't mention, or feel that I needed to mention this in relation to the immediate problem but you did ask!!! ;0)
 
I have been playing with APK's suggestions and may have found another area where the problem with ACT may lie, without having to sign on locally. Once I am definate about my resolve I'll post it in the applications section and let you know here too.
 
This has been my first days worth of postings here and this seems an excellent resource for some rapid answers.
 
Thanks again to all contributors.
 
Tricky_Luck
 
 

Since ACT requires/recommends installation using the local administrator account, that most likely means that it copies registry settings and application data utilizing the \Documents and Settings\All Users path. Of course, included in that path is the ntuser.dat, which has registry settings that will be applied to all new user accounts, or to users who do not have a local profile.
 
However; on a domain controller (which I suspect the server is, still unverified) since there are no local accounts, the ntuser.dat and the \Documents and Settings\All Users default profiles are not applied.
 
You have a few different options, some may or may not be easier than others. If you have a spare workstation you can test on, I would run Sysinternal's RegMon and FileMon during installation and inital run of ACT. Note any/all registry access/writes (copy to Notepad is easy) and you may be able to deploy those registry keys to remote users/profiles via a logon script, silently, too.
 
Also, if running of ACT requires local administrator rights, then you may need to modify your NTFS permissions accordingly, and again, Sysinternal's AccessEnum is a quick way to verify your effective NTFS permissions.
 
Hope that helps, let us know what else you need.

Hi Adam,
 
Sysinternals is exactly what I have been using, brilliant set of tools, recommend Process Explorer too, can see the ACT process running and can right click and see security permissions AND privileges, so have been playing with NTRIGHTS this afternoon, not to much success it has to be said :0(
 
The Sysinternal programs are great but still requires a lot of work, and yes, it is a Domain controller.
 
I have taken on board your points about the all users and will continue to dig through with Sysinternals,
 
Thankyou, I'll let you know how I get on tomorrow... what a pain!!!
 
Cheers
 
Tricky_Luck
 

Good luck

Right... sorry for the long delay, had a nightmare with this one but wanted to make you guys aware, this is VERY Valuble information.
 
I know we skipped onto ACT and I should have put this in the apps forum but this information is now system related.
 
While in relation to ACT and finding out why Write wouldn't fire up I was left at our last conversation going through REGMON and FILEMON. I noticed that the users didn't have CreateKey access to HKEY_CLASSES_ROOT when trying to run Write.
 
So, I added my test user giving full permissions using regedt32 (on a live terminal server) to HKEY_CLASSES_ROOT top of the tree, just for testing.
 
Disaster then insued....
 
If you ever think of adding anything to the HKEY_CLASSES_ROOT, just.... don't
 
It Removed every one of the system permissions that were there originally and gave my test user full access rights (as I had asked) and gave everyone else Read access only. ALL OTHER PERMISSIONS WERE GONE. No I didn't take any ticks out of any boxes or put any ticks in any boxes I just added my test user.
 
I thought I'd add the permissions back manually and this bought up a box saying something like , can't display user list (NULL)
 
Oh...... dear...... I thought (I have read your terms and conditions on posting!!)
 
At this point I noticed that the Inherit permissions box was unticked so I put the tick back in and clicked apply. It went away and seemed to be doing something but came back and removed the tick from the box... oh.... eeeeerrr ..... dear... I thought again.
 
After returning from the WC and using copious amounts of air-freshener the customer called to say that the server, if they logged off their terminal services session, couldn't sign back on again they got a cursor and a blue backdrop.
 
The next question was where the hell was it inheriting from, it's at the top of it's tree, AAARRGGGGHHHH.... ;(
 
To cut the rest of this long story short, the HKEY_CLASSES_ROOT looks like it is some kind of virtual like to HKEY_LOCAL_MACHINE>SOFTWARE>Classes
 
If you go to this location and reset and reapply inherited permissions it resets everything on HKEY_CLASSES_ROOT
 
It looks like this is a serious bug to me. When changes are made to the head of the HKEY_CLASSES_ROOT it is almost like it looses this "virtual link" and gives permissions to the entry you added and read access to everyone else.
 
This only applies on a Domain Controller.
 
The interesting thing was that when the user ran ACT with the full permissions the Write program from within worked, so I was on the right lines, just our Mates at Microsoft leaving leaves and twiggs covering a whacking great hole full of the days chemical toilet for us to fall into.... thanks for this one!!!
 
DON'T USE THE ABOVE SOLUTION FOR GETTING WRITE TO WORK WITHIN ACT... it worked for a day and then because we put full permissions for everyone on this key as they were all using ACT something else got screwed that stopped Office shortcuts on the desktop running but would allow you to run the executeable.... but THAT... my friends is another story.....
 
I hope this will help someone in the future, and I hope this is a useful addition to your excellent forum.
 
P.S, Microsoft, Dell, HP and all the other forums we found said that this situation called for a reload, I believe that this is the first openly available forum to actually give an answer on this
 
Thanks again for all your input,
 
Regards
 
Tricky_Luck