[gptalk] Re: Screen Saver via GPO

  • From: "Buonora, Craig \(GE, Research, consultant\)" <buonora@xxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Fri, 16 Feb 2007 13:03:18 -0500

Doug I set the screen saver name to "disabled". This setting allows users to 
change the name of the screen saver they use, if they set that to "none", the 
system will still lock like a screen saver is in place, but the LCD will just 
be blank until they move the mouse or touch a key, then the password prompt 
will appear.
 
I can send you a copy of my GPO report if that would help.
 
Good luck,
 
Craig

________________________________

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Delaney, Doug
Sent: Friday, February 16, 2007 11: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: