[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: