Archived from groups: microsoft.public.win2000.group_policy (
More info?)
Hi Bill
I'm not entirely sure but it's possible this doesn't work because the drive
mapping/load user profile processing order may not always occur in the
correct order. Is it not possible to have the user profile point to a share
and that share be dependent on the system variable?
\\%profilelocation%
Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: markreno@online.microsoft.com
Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Arizona Bill" <ArizonaBill@discussions.microsoft.com> wrote in message
news:905FA7F3-D057-419C-87F4-FF53ACC22E8F@microsoft.com...
> Mark, The second option is the one I must use. This is what I have
> currently set up. A computer script specified to the OU through GPO
> mapping a UNC share to a DRIVE (EX. V
. When I set the variable
> v:\profile ("profile" bing the Manditory profile on the server) under the
> User profile settings. The Computer script maps this UNC path. When they
> user tries to log onto the workstation and their profile is V:\profile is
> says the Profile is unable to be loaded. the Profile path is not
> available. Why is that when I map a drive in the GPO under the computer
> configuration and set it to map V: Drive to \\server1\users\ it doesn't
> always map. Now when I log onto the system and double check the drive to
> see whether or not it is mapped using a none profiled account I can double
> click on the drive V: and it takes me to the server that it is mapped to.
>
>
>
> "Mark Renoden [MSFT]" wrote:
>
>> Hi Bill
>>
>> What I'm suggesting is that you develop one single baseline mandatory
>> profile that holds all of the common elements from both desktops.
>> Customisations to this baseline mandatory profile for each desktop would
>> then be done using group policy with loopback turned on.
>>
>> If you must have two separate mandatory profiles, set a system
>> environment
>> variable that specifies the server from which the profile will come and
>> then
>> use this variable in the user profile path. Set the variable using a
>> computer startup script bound to group policy for the computer or some
>> other
>> means that suits your environment.
>>
>> Kind regards
>> --
>> Mark Renoden [MSFT]
>> Windows Platform Support Team
>> Email: markreno@online.microsoft.com
>>
>> Please note you'll need to strip ".online" from my email address to email
>> me; I'll post a response back to the group.
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Arizona Bill" <ArizonaBill@discussions.microsoft.com> wrote in message
>> news:23BA5A62-9BF7-4CDA-8BFE-4432B102885D@microsoft.com...
>> > Mark, that is exactly what I want. I want the profile to be machine
>> > specific and not user specific. Maybe I don't understand. I
>> > understand
>> > that the policy loop back defaults to the GPO Settings of the computer.
>> > But what I am not sure is how when I specify the profile path under the
>> > specified user. Lets say I have two servers Server1 and Server2 that
>> > house
>> > my two profiles. Now my staff user profile settings are
>> > \\server1\profile\staff
>> > and my student is \\server2\profile\student.
>> >
>> > Now a staff member logs onto the student workstation, and I have set in
>> > the GPO Policy Loopback. Is it going to change the profile that is
>> > loaded
>> > for server1\profile\staff -> server2\profile\student? That is where I
>> > am
>> > confused. I appoligize for my confusion.
>> >
>> > Example. User1 - Profile path \\server1\profile\user
>> >
>> >
>> >
>> > "Mark Renoden [MSFT]" wrote:
>> >
>> >> Hi Bill
>> >>
>> >> If I understand you correctly, you want profiles to be machine
>> >> specific
>> >> rather than user specific. This can all be achieved with policy
>> >> loopback.
>> >>
>> >> Kind regards
>> >> --
>> >> Mark Renoden [MSFT]
>> >> Windows Platform Support Team
>> >> Email: markreno@online.microsoft.com
>> >>
>> >> Please note you'll need to strip ".online" from my email address to
>> >> email
>> >> me; I'll post a response back to the group.
>> >>
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >>
>> >> "Arizona Bill" <ArizonaBill@discussions.microsoft.com> wrote in
>> >> message
>> >> news:1739C21C-2A4F-425A-ACF7-17A87B1E68EA@microsoft.com...
>> >> > Mark,
>> >> >
>> >> > Basically, The Staff members have a manditory profile as do the
>> >> > student
>> >> > have a manitory profile. They are two separt profiles located on
>> >> > two
>> >> > different VLans. When a staff member sits at a student workstation
>> >> > on
>> >> > a
>> >> > separate VLan they will logon with the student profile. The items
>> >> > that
>> >> > are set in the profile are there Start -> Programs and any
>> >> > applications
>> >> > they might use.
>> >> >
>> >> > What I would like to be able to do is Map A network drive on the
>> >> > computer
>> >> > start up the V drive. it would look something like this
>> >> >
>> >> > \\server\profile =V drive
>> >> >
>> >> > Under the V drive there would be folders specified profile1,
>> >> > profile2,
>> >> > profile3, etc.
>> >> >
>> >> > Then in the User's profile path I would enter V:\profile1 for
>> >> > example
>> >> > and
>> >> > the user would log on and pull that profile.
>> >> >
>> >> >
>> >> > "Mark Renoden [MSFT]" wrote:
>> >> >
>> >> >> Hi Bill
>> >> >>
>> >> >> Without testing myself, you could use "set" in a startup script
>> >> >> assigned
>> >> >> to
>> >> >> the computers via Group Policy.
>> >> >>
>> >> >> I don't follow your explanation of the the requirement. Can you
>> >> >> clarify?
>> >> >>
>> >> >> Kind regards
>> >> >> --
>> >> >> Mark Renoden [MSFT]
>> >> >> Windows Platform Support Team
>> >> >> Email: markreno@online.microsoft.com
>> >> >>
>> >> >> Please note you'll need to strip ".online" from my email address to
>> >> >> email
>> >> >> me; I'll post a response back to the group.
>> >> >>
>> >> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> >> rights.
>> >> >>
>> >> >> "Arizona Bill" <ArizonaBill@discussions.microsoft.com> wrote in
>> >> >> message
>> >> >> news:52F3B7FD-EA63-419D-9AF3-86EBC567B3DE@microsoft.com...
>> >> >> > Mark, Thanks your assistance on this. That could possibly work
>> >> >> > but
>> >> >> > how
>> >> >> > should I set the %profileserver% environment on client boot?
>> >> >> >
>> >> >> > The main issue I have is that our CTO wants to be staff members
>> >> >> > to
>> >> >> > be
>> >> >> > able
>> >> >> > to user student workstations and pull the student profile.
>> >> >> > Having
>> >> >> > all
>> >> >> > the
>> >> >> > start->program files-> and applications that a student we be able
>> >> >> > to
>> >> >> > use.
>> >> >> > Student that are part of a special topic class that has
>> >> >> > designated
>> >> >> > machines with specific apps only showing those specific apps on
>> >> >> > the
>> >> >> > client
>> >> >> > machines.
>> >> >> >
>> >> >> > "Mark Renoden [MSFT]" wrote:
>> >> >> >
>> >> >> >> Hi Bill
>> >> >> >>
>> >> >> >> I'm pretty sure the answer is no. I assume you want the server
>> >> >> >> name
>> >> >> >> to
>> >> >> >> be
>> >> >> >> different depending on which client machine you log onto? The
>> >> >> >> only
>> >> >> >> way I
>> >> >> >> can see you achieving this is to set the user profile path to
>> >> >> >> something
>> >> >> >> like
>> >> >> >> \\%profileserver%\users\%username% and set the %profileserver%
>> >> >> >> environment
>> >> >> >> variable when the client boots.
>> >> >> >>
>> >> >> >> Probably a better approach is to identify which settings should
>> >> >> >> be
>> >> >> >> common
>> >> >> >> across all client machines and implement those in a GPO linked
>> >> >> >> to
>> >> >> >> an
>> >> >> >> OU.
>> >> >> >> Inside that OU, create OU's for specific client machine sets and
>> >> >> >> apply
>> >> >> >> another GPO to each of those OU's that set the unique settings
>> >> >> >> for
>> >> >> >> that
>> >> >> >> group of client machines. If the policy settings are specific
>> >> >> >> to
>> >> >> >> the
>> >> >> >> "User
>> >> >> >> Configuration" parts of the GPO's, you can use policy loopback
>> >> >> >> as I
>> >> >> >> mentioned earlier:
>> >> >> >>
>> >> >> >>
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/grppolsc.mspx
>> >> >> >>
>> >> >> >> It's really worthwhile reading the document that I mentioned
>> >> >> >> before.
>> >> >> >> If
>> >> >> >> it
>> >> >> >> doesn't answer your questions specifically, it'll give some good
>> >> >> >> practices
>> >> >> >> that you can then adapt to your specific scenario.
>> >> >> >>
>> >> >> >> Kind regards
>> >> >> >> --
>> >> >> >> Mark Renoden [MSFT]
>> >> >> >> Windows Platform Support Team
>> >> >> >> Email: markreno@online.microsoft.com
>> >> >> >>
>> >> >> >> Please note you'll need to strip ".online" from my email address
>> >> >> >> to
>> >> >> >> email
>> >> >> >> me; I'll post a response back to the group.
>> >> >> >>
>> >> >> >> This posting is provided "AS IS" with no warranties, and confers
>> >> >> >> no
>> >> >> >> rights.
>> >> >> >>
>> >> >> >> "Arizona Bill" <ArizonaBill@discussions.microsoft.com> wrote in
>> >> >> >> message
>> >> >> >> news:F3B2E586-57B5-49FE-BA5A-4226CF6AB816@microsoft.com...
>> >> >> >> > Mark, can you tell me if this is possible?
>> >> >> >> >
>> >> >> >> > I am trying to find out information in regards to whether or
>> >> >> >> > not
>> >> >> >> > this
>> >> >> >> > can
>> >> >> >> > be done. I am currently running an Windows 2000 active
>> >> >> >> > directory
>> >> >> >> > will
>> >> >> >> > all
>> >> >> >> > windows xp pro sp1 clients. I have been asked to Map User
>> >> >> >> > profiles
>> >> >> >> > to
>> >> >> >> > a
>> >> >> >> > network drive. Ex. z:\profile. The problem is that I have
>> >> >> >> > created
>> >> >> >> > a
>> >> >> >> > VBS
>> >> >> >> > script to run in the computer script section of Group Policy
>> >> >> >> > for
>> >> >> >> > the
>> >> >> >> > Organizational Unit where the machine resides when the machine
>> >> >> >> > boots
>> >> >> >> > up.
>> >> >> >> > (MapNetworkDrive "z:", "\\server\users)
>> >> >> >> >
>> >> >> >> > The purpose of this is to map specified manditory profiles to
>> >> >> >> > workstations
>> >> >> >> > and not the Users. When Implemented, a user logs in and a
>> >> >> >> > message
>> >> >> >> > window
>> >> >> >> > appears stating that it is unable to find the roaming profile.
>> >> >> >> > When
>> >> >> >> > a
>> >> >> >> > non-profiled account logs onto the system and opens "My
>> >> >> >> > Computer"
>> >> >> >> > the
>> >> >> >> > mapped dirve Z:\profile is there. When you double click on
>> >> >> >> > the
>> >> >> >> > drive
>> >> >> >> > it
>> >> >> >> > takes you to the share.
>> >> >> >> >
>> >> >> >> > I question is: Is it possible to map user profiles to a
>> >> >> >> > network
>> >> >> >> > drive
>> >> >> >> > that is mapped when the workstation authenticates to the AD
>> >> >> >> > network?
>> >> >> >> > I
>> >> >> >> > don't want to make the user profile to a UNC Path name Ex.
>> >> >> >> > \\server\users\%username% but instead to Z:\%username%
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > "Mark Renoden [MSFT]" wrote:
>> >> >> >> >
>> >> >> >> >> Hi Tim/Bill
>> >> >> >> >>
>> >> >> >> >> Consider designing GPO/s that include settings for the users
>> >> >> >> >> that
>> >> >> >> >> are
>> >> >> >> >> common
>> >> >> >> >> across all computers and then implementing the differing
>> >> >> >> >> settings
>> >> >> >> >> using
>> >> >> >> >> policy in the computer configuration. Another option is
>> >> >> >> >> policy
>> >> >> >> >> loopback:
>> >> >> >> >>
>> >> >> >> >> 231287 Loopback Processing of Group Policy
>> >> >> >> >>
http://support.microsoft.com/?id=231287
>> >> >> >> >>
>> >> >> >> >> The following document may be useful (although not specific
>> >> >> >> >> to
>> >> >> >> >> your
>> >> >> >> >> needs):
>> >> >> >> >>
>> >> >> >> >>
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/grppolsc.mspx
>> >> >> >> >>
>> >> >> >> >> Kind regards
>> >> >> >> >> --
>> >> >> >> >> Mark Renoden [MSFT]
>> >> >> >> >> Windows Platform Support Team
>> >> >> >> >> Email: markreno@online.microsoft.com
>> >> >> >> >>
>> >> >> >> >> Please note you'll need to strip ".online" from my email
>> >> >> >> >> address
>> >> >> >> >> to
>> >> >> >> >> email
>> >> >> >> >> me; I'll post a response back to the group.
>> >> >> >> >>
>> >> >> >> >> This posting is provided "AS IS" with no warranties, and
>> >> >> >> >> confers
>> >> >> >> >> no
>> >> >> >> >> rights.
>> >> >> >> >>
>> >> >> >> >> "Arizona Bill" <Arizona Bill@discussions.microsoft.com> wrote
>> >> >> >> >> in
>> >> >> >> >> message
>> >> >> >> >> news:01B819AE-6ADA-46A5-9A4F-214FFD702B12@microsoft.com...
>> >> >> >> >> > Tim, I am also having the same issues. I have manditory
>> >> >> >> >> > profiles
>> >> >> >> >> > set
>> >> >> >> >> > for
>> >> >> >> >> > users but have mutiple computers with differ applications.
>> >> >> >> >> > If
>> >> >> >> >> > a
>> >> >> >> >> > profile
>> >> >> >> >> > can be based on OU or mapping a profile to a drive letter
>> >> >> >> >> > which
>> >> >> >> >> > is
>> >> >> >> >> > mapped
>> >> >> >> >> > via a VBS Script based in the OU GPO.
>> >> >> >> >> >
>> >> >> >> >> > Can anyone shed any light on this issue?
>> >> >> >> >> >
>> >> >> >> >> > "Tim" wrote:
>> >> >> >> >> >
>> >> >> >> >> >> Does anyone know of a way to assign a mandatory profile
>> >> >> >> >> >> based on the computer that the user logs on to. We are in
>> >> >> >> >> >> a college setting and not all of our computers have the
>> >> >> >> >> >> same programs. We want to assign a standard profile to be
>> >> >> >> >> >> used by students but do not want dead shortcuts on the
>> >> >> >> >> >> desktop. We could easily create seperate profiles to be
>> >> >> >> >> >> used based on computer location OU, but is this possible?
>> >> >> >> >> >>
>> >> >> >> >> >> Thanks,
>> >> >> >> >> >> Tim
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>