XP SP2

We are in the process of restricting all our employees to standard user
accounts on the desktop. For the most part this has all gone just fine, but
today I ran into a problem that I have not previously encountered. I
converted a group of users to standard user accounts and all of them lost
the ability to launch Attachmate Extra from the desktop icon. Now, I tested
Extra in advance and found that I needed to tweak the NTFS permissions to
make it run as a standard user, and I added the appropriate file rights to
our group policy. In fact, I currently have standard users running Extra
without problems, so I know that I've got that end of things nailed down.
The problem today was that the desktop icon does not work, and when I
checked the properties of the icon I found that all the fields had been
emptied out. This situation never arose in our testing.

I have the same problem with another product called BeyondCompare.

Both the Extra and BeyondCompare icons are located on the All Users desktop.
There are other icons on the All Users desktop that appear to have been
unaffected, or at least no one complained about them today.

Does anyone know why the icons for these two products were essentially made
into empty shells simply by removing the admin rights of the user? Does
this have something to do with the way the installation packages for these
products created the shortcuts? Also, can I possibly fix the problem by
giving the user rights to those specific icons via the group policy?

Any information you can offer will be greatly appreciated.

--Tom

The date and time was 2/28/2008 5:35 PM, and on a whim, Thomas M.
pounded out on the keyboard:


> XP SP2
>
> We are in the process of restricting all our employees to standard user
> accounts on the desktop. For the most part this has all gone just fine, but
> today I ran into a problem that I have not previously encountered. I
> converted a group of users to standard user accounts and all of them lost
> the ability to launch Attachmate Extra from the desktop icon. Now, I tested
> Extra in advance and found that I needed to tweak the NTFS permissions to
> make it run as a standard user, and I added the appropriate file rights to
> our group policy. In fact, I currently have standard users running Extra
> without problems, so I know that I've got that end of things nailed down.
> The problem today was that the desktop icon does not work, and when I
> checked the properties of the icon I found that all the fields had been
> emptied out. This situation never arose in our testing.
>
> I have the same problem with another product called BeyondCompare.
>
> Both the Extra and BeyondCompare icons are located on the All Users desktop.
> There are other icons on the All Users desktop that appear to have been
> unaffected, or at least no one complained about them today.
>
> Does anyone know why the icons for these two products were essentially made
> into empty shells simply by removing the admin rights of the user? Does
> this have something to do with the way the installation packages for these
> products created the shortcuts? Also, can I possibly fix the problem by
> giving the user rights to those specific icons via the group policy?
>
> Any information you can offer will be greatly appreciated.
>
> --Tom
>
>

Hi Tom,

We have users connecting to TS via RDP, and I had to add user rights to
the specific icons in order for the user to gain access to the program.
That may be the same in your situation.

--
Terry R.

***Reply Note***
Anti-spam measures are included in my email address.
Delete NOSPAM from the email address after clicking Reply.

"Terry R." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> The date and time was 2/28/2008 5:35 PM, and on a whim, Thomas M. pounded
> out on the keyboard:
>
>
>> XP SP2
>>
>> We are in the process of restricting all our employees to standard user
>> accounts on the desktop. For the most part this has all gone just fine,
>> but today I ran into a problem that I have not previously encountered. I
>> converted a group of users to standard user accounts and all of them lost
>> the ability to launch Attachmate Extra from the desktop icon. Now, I
>> tested Extra in advance and found that I needed to tweak the NTFS
>> permissions to make it run as a standard user, and I added the
>> appropriate file rights to our group policy. In fact, I currently have
>> standard users running Extra without problems, so I know that I've got
>> that end of things nailed down. The problem today was that the desktop
>> icon does not work, and when I checked the properties of the icon I found
>> that all the fields had been emptied out. This situation never arose in
>> our testing.
>>
>> I have the same problem with another product called BeyondCompare.
>>
>> Both the Extra and BeyondCompare icons are located on the All Users
>> desktop. There are other icons on the All Users desktop that appear to
>> have been unaffected, or at least no one complained about them today.
>>
>> Does anyone know why the icons for these two products were essentially
>> made into empty shells simply by removing the admin rights of the user?
>> Does this have something to do with the way the installation packages for
>> these products created the shortcuts? Also, can I possibly fix the
>> problem by giving the user rights to those specific icons via the group
>> policy?
>>
>> Any information you can offer will be greatly appreciated.
>>
>> --Tom
>
> Hi Tom,
>
> We have users connecting to TS via RDP, and I had to add user rights to
> the specific icons in order for the user to gain access to the program.
> That may be the same in your situation.
>
> --
> Terry R.
>
> ***Reply Note***
> Anti-spam measures are included in my email address.
> Delete NOSPAM from the email address after clicking Reply.

That's what I was thinking. Interestingly, I found out this morning that
the users having problems are running version 7.1 of Extra, and another user
who is running version 8 and tried it for the first time just this morning
is not having a problem. So I think that my solution is upgrading users to
version 8.

In general terms, I'm kind of thinking that the installation process for
some applications may give the desktop icon some special properties, kind of
like the way that the My Documents icon and the Outlook icons have special
properties beyond what you get with just your basic icon, but that's just a
wild guess.

I'll try to do some testing on this next week and will try to report back
for the benefit of anyone who is interested.

--Tom

>> Hi Tom,
>>
>> We have users connecting to TS via RDP, and I had to add user rights to
>> the specific icons in order for the user to gain access to the program.
>> That may be the same in your situation.
>>
>> --
>> Terry R.
>>
>> ***Reply Note***
>> Anti-spam measures are included in my email address.
>> Delete NOSPAM from the email address after clicking Reply.
>
> That's what I was thinking. Interestingly, I found out this morning that
> the users having problems are running version 7.1 of Extra, and another
> user who is running version 8 and tried it for the first time just this
> morning is not having a problem. So I think that my solution is upgrading
> users to version 8.
>
> In general terms, I'm kind of thinking that the installation process for
> some applications may give the desktop icon some special properties, kind
> of like the way that the My Documents icon and the Outlook icons have
> special properties beyond what you get with just your basic icon, but
> that's just a wild guess.
>
> I'll try to do some testing on this next week and will try to report back
> for the benefit of anyone who is interested.
>
> --Tom

I have identified the problem, and it turns out that it was an issue that my
previous testing *did* identify. Unfortunately, the write-up of my notes
from that testing was a little unclear and I just couldn't quite pull the
information out of the ol' memory banks. Basically, the Extra session file
is customizable and because of that we install the session file to the My
Document folder (or some other location that a standard user account can
access). In this particular case the software had been installed a long
time ago, before we started locking down desktops, and that session file got
installed to the application folder under Program Files, which a standard
user account cannot write to, so when we took away the admin rights of that
user he lost the ability to launch the session from that location because
the software was looking for write permissions to that folder. Once I
assigned the write permissions it started working again.

It shouldn't have taken me so long to realize the problem, but truth be told
I was only giving it half my attention because I have had bigger fish to fry
lately. Once I got the time to give it my full attention it was a real
Homer Simpson "DOH!" moment! ;-)

--Tom