[gptalk] Re: Screen Saver via GPO
- From: "Nelson, Jamie R Contr 72 CS/SCBNF" <Jamie.Nelson.ctr@xxxxxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Fri, 16 Feb 2007 12:07:44 -0600
Yeah, but even if they select "none" as their screen saver, the system will
still lock if you have password protection and a timeout enforced. What leads
you to believe that it won't?
Note: I just tested on my system, with password protection and a 5-minute
timeout enforced. It locked, but no screen saver activated.
//signed//
Jamie R Nelson
Systems Engineer
Ingenium Corporation
72 CS/SCBNF
405.739.2811 (DSN 339)
________________________________
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Delaney, Doug
Sent: Friday, February 16, 2007 10:38 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Screen Saver via GPO
What I meant is, if they select none, the policy applied settings are no longer
enforced.
But, you know executives have to be able to use their custom screen savers...
family pictures... cats and dogs... whatever, yet they want it secured.
Doug Delaney
GM Desktop Engineering
Global Client Engineering GM
1075 W. Entrance Dr., MS 2B, Cube 2130
Auburn Hills, MI 48326
Lab: 248-365-9187
Tel: 248-754-7917
Pg: 248-870-0306 pager
Mail: Doug.Delaney@xxxxxxx <mailto:Doug.Delaney@xxxxxxx>
Note: The information in this email is intended solely for the addressee.
Access to this email by anyone else is unauthorized. If you are not the
intended recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it is prohibited.
________________________________
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
On Behalf Of Nelson, Jamie R Contr 72 CS/SCBNF
Sent: Friday, February 16, 2007 11:19 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Screen Saver via GPO
What "other" settings are you worried about your users changing? I know
you can force the timeout and lock workstation settings, but you can't prevent
them from selecting none unless you actually set a specific screen saver.
//signed//
Jamie R Nelson
Systems Engineer
Ingenium Corporation
72 CS/SCBNF
405.739.2811 (DSN 339)
________________________________
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
On Behalf Of Delaney, Doug
Sent: Friday, February 16, 2007 9:58 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Screen Saver via GPO
Hi,
Does anyone know how to lock down the screen saver via GPO without
having to specify the screen saver executable itself? I only want to lock down
the timeout, and the password protection and not allow the user to be able to
select (none) for the screen saver - which lets them then change other settings.
Doug Delaney
GM Desktop Engineering
Global Client Engineering GM
1075 W. Entrance Dr., MS 2B, Cube 2130
Auburn Hills, MI 48326
Lab: 248-365-9187
Tel: 248-754-7917
Pg: 248-870-0306 pager
Mail: Doug.Delaney@xxxxxxx <mailto:Doug.Delaney@xxxxxxx>
Note: The information in this email is intended solely for the
addressee. Access to this email by anyone else is unauthorized. If you are not
the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it is prohibited.
________________________________
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, February 16, 2007 9:50 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
Strange-
Fast Logon Optimization shouldn't result in access denied
errors but maybe its an issue with network timing. In any case, I usually tell
folks to enable that by default because it saves on the multiple reboots and
logons for stuff like software installation and folder redirection. Glad to
hear it worked!
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Judd
Sent: Friday, February 16, 2007 5:42 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
OK
Jamie I have tried the following read through the articles and
the only one that I hadn't applied appears to have made a difference KB305293
Fast Logon Optimization - I enabled the policy relating to this and WHAM the
apps installed. SO A HUGE THANKYOU MATE.
Darren - MARK IT UP
Regards
Craig
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Nelson, Jamie R Contr 72
CS/SCBNF
Sent: 15 February 2007 16:55
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
Craig,
Are you sure your share/NTFS permissions are not conflicting
somehow? Remember, the most restrictive of the two will always win out.
//signed//
Jamie R Nelson
Systems Engineer
Ingenium Corporation
72 CS/SCBNF
405.739.2811 (DSN 339)
________________________________
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Judd
Sent: Thursday, February 15, 2007 10:21 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
Darren
That was my understanding also, however it seemed like a good
Idea to try this prior to Jamie's solution from yesterday. It certainly appears
that the policy is running, and then failing to access the resources, this is
what the installer log file says, so it seemed like a good first plan.
However the syntax of the request seems to fail when I do it
from the command line, I will now try Thorbjorn's syntax and see if that works
or fails, I am expecting it to fail again. Then I would like to know what ACL's
need to be in place on an application share folder where the source MSI exists
for successful application deployment.
Regards
Craig
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: 15 February 2007 14:53
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
Thorbjorn-
I would think this would not work at all from the LocalSystem
account because in order for it to access network resources, it would need to
impersonate the machine account, which I didn't think was an automatic thing
(i.e. during GP processing, there is an explicit call to ImpersonateUser).
Darren
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Thorbjörn Sjövold
Sent: Thursday, February 15, 2007 5:14 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
My suggestion was something like (If your AD domain DNS name is
for example "parkstone.local")
DIR \\parkstone.local\SYSYVOL\parkstone.local
<file:///\\parkstone.local\SYSYVOL\parkstone.local> (from a client where you
are experiencing the problem)
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com <http://www.specopssoft.com/>
thorbjorn.sjovold a t specopssoft.com
Download our free tool for remote Gpupdate with graphical
reporting,
http://www.specopssoft.com/products/specopsgpupdate/
________________________________
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Judd
Sent: den 15 februari 2007 13:49
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
Thanks Thorbjörn
I have again run an interactive session and tried what you
said, but cannot seem to connect to the SYSVOL
When I run NET VIEW from the domain controller in question I
can see all the shares including NETLOGON AND SYSVOL but yet when I try to open
them I receive the following error.
"SYSTEM ERROR 123
The filename, Directory Name, or Volume label syntax is
incorrect."
When you suggested connecting to
\\<domain.rootdomain\SYSVOL\<domain.rootdomain
<file:///\\%3cdomain.rootdomain\SYSVOL\%3cdomain.rootdomain> what exact
syntax should I use for this.
Thanks
Craig
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Thorbjörn Sjövold
Sent: 15 February 2007 10:00
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
You are running with the system credentials (system level) but
you get prompted for credentials because the Redirector (Workstation service)
figures out that to access the resources you request the current ones are
inadequate. On the network the mighty Local System account is just another
user, if you have security logging enabled on your share you would find the
computer name with a $ sign , e.g. "mycomputer$" sign after it as it it is the
computer SAM account name that is used when a computer is trying to access
something.
Your account obviously are still connected to the domain, since
Group Policy is processing fine. In the System command prompt I assume you can
read from SYSVOL. i.e. \\<domain.rootdomain\SYSVOL\<domain.rootdomain
<file:///\\%3cdomain.rootdomain\SYSVOL\%3cdomain.rootdomain> ? Also do you
have any problems accessing the shares as an ordinary user and not as the
computer?
HTH,
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com <http://www.specopssoft.com/>
thorbjorn.sjovold a t specopssoft.com
Download our free tool for remote Gpupdate with graphical
reporting,
http://www.specopssoft.com/products/specopsgpupdate/
________________________________
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Judd
Sent: den 15 februari 2007 10:21
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
I did try this, it seems like an excellent way to determine
access rights from the system level. I obviously have a problem because I am
trying to connect to our shares
Net view \\10.1.1.10\[sharename
<file:///\\10.1.1.10\%5bsharename> ] and I get the error
"System error 5 Access is denied" - this seems to be blanket
across all shares, even if I have "everyone" read only and the "domain
computers" read only on the shares and file level security.
If I Net Use * \\10.1.1.10\[sharename
<file:///\\10.1.1.10\%5bsharename> ] I get prompted for username and password.
But I thought this was running at the system level?
Any ideas?
Regards
Craig
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Thorbjörn Sjövold
Sent: 14 February 2007 15:22
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
If this is a computer based deployment, here is a neat little
trick to check if this is permission problem:
1) Log on as an administrator on a computer where you have the
problem.
2) Start a Command Prompt
3) Run the command "AT <A time close to now> /Interactive
cmd.exe"
4) When the jobs runs a new command prompt will pop up where
you are actually running with the security credentials as the System, i.e. the
computer account.
5) Try to access the path where your files are located using
for example DIR from the new command prompt. If you get an Access Denied here
then you know it is a permission problem.
Observe that this will not work in Vista due to all services
and the system itself now have their Windows Stations in Session 0 and we
mortals do not :)
HTH,
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com <http://www.specopssoft.com/>
thorbjorn.sjovold a t specopssoft.com
Download our free tool for remote Gpupdate with graphical
reporting,
http://www.specopssoft.com/products/specopsgpupdate/
________________________________
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: den 14 februari 2007 15:58
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails
Craig-
This is a common problem I see and I'll be darned if I can find
a common thread. But, some things to check. If you are deploying per-computer,
try granting the Domain Computers group explicit read access to these shares
and files. I know that it shouldn't matter if you already have the Everyone
group but I have seen this help. 2nd thing-if the servers are 2003, SP1, there
may be some SMB signing going on that the clients can't handle. Make sure that
your security settings on the servers don't require SMB signing or that your
clients are set to respond to it.
Those are the two things that come to mind right away. Let us
know if neither helps.
Darren
From: gptalk-bounce@xxxxxxxxxxxxx
[mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Judd
Sent: Wednesday, February 14, 2007 12:45 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Installing Applications Fails
Hi
We have a medium sized Active Directory that has been in place
for about 3 yrs, apart from the deployment of the Office Suite against the
"domain policy" we have OU's that represent each group of machines and in turn
we have associated applications for each department trying to install from
these OU's. The office installation succeeds by the way.
However it has come to light that these other apps fail to be
deployed successfully, the LOG entry says that the "source installation file is
not available".
So we see that when we reboot a client workstation it says that
it is installing the required application, it all appears to go through ok, the
log in box finally appears, but yet the deployed application has not been
installed.
The source files are available at the share location, and all
security and rights are available to everyone as read only.
Any pointers as to why the apps are failing to deploy would be
a huge help, thanks in advance.
Craig Judd
ICT Network Manager
Parkstone Grammar School,
Sopers Lane,
Poole,
Dorset.
BH17 7EP
01202 605617
Other related posts:
