server2003 question.

  • Thread starter Thread starter Mike Hyndman
  • Start date Start date
M

Mike Hyndman

This question is on behalf of a school who is having a network problem
with a new installation (installers have ceased trading) and if it is
the wrong ng, my apologies.

The main problem, (there are several), is that all the application
programs are installed on the server. Some, not all of these programs
should then made available to different domain groups, depending on
their ability. (I didn't know that this was possible without third party
software such as "Ranger" et al)

How it should work then is this, the user logs on to the domain, he/she
then only sees the programs, as shortcuts on his desktop, he/she is
entitled to use.

What has happened is that the wrong programs are being made available at
log on and the staff do not know where to look to assign the relevant
applications to the domain users. Why this wasn't picked up just after
the network was installed is a mystery. They've looked in Group
policies etc. (I assume on the server) but have not been able to find
anything.They have also tried the MSKB without success.

The network consists of the 2003 server, new Win XP Pro PC's with a
small number of W98 PC's, the latter taking more than five minutes to
log on to the server. When this was questioned, the installers, prior to
liquidating, said quote, "it's was due to the age of the machines and
them having to draw "power" from the server" What's all that about?

Again, my apologies if this is the wrong ng and if the question seems a
little vague but I am getting all this info second hand, but any help
whatsoever with this problem would be most gratefully received.
Regards
Mike H
remove -bats- to reply

"Ingratitude is never having to say thankyou".
 
Mike,

I'm afraid I can't answer your questions but please let us all know what you
find out. My daughter's school wants "a server" and also runs Win95, Win98,
WinXP etc. but currently as a collection of peer-to-peer machines.

Your questions sound like exactly the sorts of things that I will need to
address before the school jumps in and "buys before they look".

BTW, is this an independent school? I ask because one question I have yet
to ask is "doesn't the LEA have someone who co-ordinates ICT between schools
at the hardware level"?

Paul DS.
 
You cannot assign desktop shortcuts in group policy. You can create a
default user profile in the \\domain-controller\netlogon share that will
apply to all NEW users, but not to existing ones. You could put folders
named for the groups with shortcuts to the shares/apps on the server that
that group is supposd to run. You could permit access to only the shared
resources that group is entitled to use. This wold hafve been much easier if
it were addresses in the pre-deployment planning stage.

....kurt
 
You cannot assign desktop shortcuts in group policy. You can create a
default user profile in the \\domain-controller\netlogon share that will
apply to all NEW users, but not to existing ones. You could put folders
named for the groups with shortcuts to the shares/apps on the server that
that group is supposd to run. You could permit access to only the shared
resources that group is entitled to use. This wold hafve been much easier if
it were addresses in the pre-deployment planning stage.

...kurt
Click to expand...
Many thanks Kurt,

Is it possible that the domain users program access rights are allocated
via a logon script and if so, where would the log on script be kept in
Server 2003?
Pre deployment planning stage, what's one of those? ;-)

Again many thanks,

Mike H
remove -bats- to reply

"Ingratitude is never having to say thankyou".
 
Permissions are allocated (usually) via the security ACLs on the folders
containing the applications. On the server, right click the folder, select
properties then the security tab. There you can modify the permissions for
who has what type of access to items in that folder. You'll still need to
add items to the user's desktops. If it's just a few users, I'd probably
create folders on the server with shortcuts to the applications using the
UNC path (\\server\share), then put a UNC shortcut on the user's desktops to
that. If you do it that way, when something needs to be changed, added or
deleted, you can just do it once on the server share, and it's done for
everybody. If you have a lot of users, you could script adding the shortcut
to the desktops with a WSH script. You'd have to look into that on your own.

Check out the scripting guys:
http://www.microsoft.com/technet/scriptcenter/resources/qanda/default.mspx

and

Check out this excellent set of remote management tools

http://www.sysinternals.com/Utilities/PsTools.html

....kurt


Many thanks Kurt,

Is it possible that the domain users program access rights are allocated
via a logon script and if so, where would the log on script be kept in
Server 2003?
Pre deployment planning stage, what's one of those? ;-)

Again many thanks,

Mike H
remove -bats- to reply

"Ingratitude is never having to say thankyou".
 
Permissions are allocated (usually) via the security ACLs on the folders
containing the applications. On the server, right click the folder, select
properties then the security tab. There you can modify the permissions for
who has what type of access to items in that folder. You'll still need to
add items to the user's desktops. If it's just a few users, I'd probably
create folders on the server with shortcuts to the applications using the
UNC path (\\server\share), then put a UNC shortcut on the user's desktops to
that. If you do it that way, when something needs to be changed, added or
deleted, you can just do it once on the server share, and it's done for
everybody. If you have a lot of users, you could script adding the shortcut
to the desktops with a WSH script. You'd have to look into that on your own.

Check out the scripting guys:
http://www.microsoft.com/technet/scriptcenter/resources/qanda/default.mspx

and

Check out this excellent set of remote management tools

http://www.sysinternals.com/Utilities/PsTools.html

...kurt
Click to expand...
Kurt,

Again many thanks for the info and the links, now at least we may be
able to implement a "post" deployment planning stage.
Regards
Mike Hyndman
remove -bats- to reply

"Ingratitude is never having to say thankyou".
 
Permissions are allocated (usually) via the security ACLs on the folders
containing the applications. On the server, right click the folder, select
properties then the security tab. There you can modify the permissions for
who has what type of access to items in that folder. You'll still need to
add items to the user's desktops. If it's just a few users, I'd probably
create folders on the server with shortcuts to the applications using the
UNC path (\\server\share), then put a UNC shortcut on the user's desktops to
that. If you do it that way, when something needs to be changed, added or
deleted, you can just do it once on the server share, and it's done for
everybody. If you have a lot of users, you could script adding the shortcut
to the desktops with a WSH script. You'd have to look into that on your own.
Click to expand...

Kurt,
I've looked at the server and the user's desktops are being generated
via a startup folder (similar to your suggestion) which resides in a
parent folder called "Outbound" (don't know if this is a default S2003
folder or installer created) and is triggered from a startup "folder
redirection" instruction dialogue in the desktop area of the GP of the
server.

What I was unable to do was to save any changes I made to the users
desktop, everytime I logged out and back in again the changes had
dissapeared. I checked the "do not save settings on exit" in the Desktop
area of GP on the server and it was enabled. No matter what setting I
applied to this feature (enabled, disabled not configured) it had no
effect on the changes made to the user's desktop. Is this because the
user's desktop was being generated from the server at log on and
therefore overriding local changes?

Additions made to the "startup" folder on the server were remembered OK
and duly appeared on the user's desktop. I ran gpedit.msc on the client
PC's and all the settings were still at "not configured" so, the server
must be controlling the appearance and settings of the client PC's
desktop , yes?

Another problem is that not all of the software installed centrally
(and run OK) on the server will run from the client PC's, some apps just
hang and others ask for a CD even when the network version of the progs
have been installed. I suggested that they contact the software
publishers re this problem.

Is it worth posting this to a server ng as well?

Regards
Mike H

remove -bats- to reply

"Ingratitude is never having to say thankyou".
 
Permissions are allocated (usually) via the security ACLs on the folders
containing the applications. On the server, right click the folder, select
properties then the security tab. There you can modify the permissions for
who has what type of access to items in that folder. You'll still need to
add items to the user's desktops. If it's just a few users, I'd probably
create folders on the server with shortcuts to the applications using the
UNC path (\\server\share), then put a UNC shortcut on the user's desktops to
that. If you do it that way, when something needs to be changed, added or
deleted, you can just do it once on the server share, and it's done for
everybody. If you have a lot of users, you could script adding the shortcut
to the desktops with a WSH script. You'd have to look into that on your own.
Click to expand...

Kurt,
I've looked at the server and the user's desktops are being generated
via a startup folder (similar to your suggestion) which resides in a
parent folder called "Outbound" (don't know if this is a default S2003
folder or installer created) and is triggered from a startup "folder
redirection" instruction dialogue in the desktop area of the GP of the
server.

What I was unable to do was to save any changes I made to the users
desktop, everytime I logged out and back in again the changes had
dissapeared. I checked the "do not save settings on exit" in the Desktop
area of GP on the server and it was enabled. No matter what setting I
applied to this feature (enabled, disabled not configured) it had no
effect on the changes made to the user's desktop. Is this because the
user's desktop was being generated from the server at log on and
therefore overriding local changes?

Additions made to the "startup" folder on the server were remembered OK
and duly appeared on the user's desktop. I ran gpedit.msc on the client
PC's and all the settings were still at "not configured" so, the server
must be controlling the appearance and settings of the client PC's
desktop , yes?

Another problem is that not all of the software installed centrally
(and run OK) on the server will run from the client PC's, some apps just
hang and others ask for a CD even when the network version of the progs
have been installed. I suggested that they contact the software
publishers re this problem.

Is it worth posting this to a server ng as well?

Regards
Mike H

remove -bats- to reply

"Ingratitude is never having to say thankyou".
 
There is a policy somewhere that doesn't allow users to change desktops (or
many aspects of it). I hate blanket policies, where s GPO is created and
everything is thrown into it. I prefer to create many GPOs named
appropriately for what they do and apply them at the approporiate level
(site, domain, OU). Going back and trying to figure out what someone else
did in your situation is very difficult. There are probably many ways to do
what you are describing. Some things to check out.

Group policy (deeper)
Mandatory User Profiles
Folder re-direction

Also look at "resultant set of policy"

.....kurt
 
There is a policy somewhere that doesn't allow users to change desktops (or
many aspects of it). I hate blanket policies, where s GPO is created and
everything is thrown into it. I prefer to create many GPOs named
appropriately for what they do and apply them at the approporiate level
(site, domain, OU). Going back and trying to figure out what someone else
did in your situation is very difficult. we're finding that out ;-)
There are probably many ways to do
what you are describing. Some things to check out.

Group policy (deeper)
Mandatory User Profiles
Folder re-direction

Also look at "resultant set of policy"

....kurt
Click to expand...
Kurt,

Many thanks for your suggestions.

Regards
Mike H
remove -bats- to reply

"Ingratitude is never having to say thankyou".
 
Back
Top