Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Cannot get rid of GPO SCRIPT error on all network PC's - suspect printers


  • Please log in to reply
7 replies to this topic

#1 searcherrr

searcherrr

  • Members
  • 5 posts
  • OFFLINE
  •  
  • Local time:01:35 PM

Posted 25 August 2014 - 03:39 PM

I do believe that pushprinterconnections.exe is not needed for a network setup comprised of Windows 7 fat clients and Windows Server 2008 R2 for deploying printers, though at the time I tried to do this setup, I didn't know that. Even if that isn't the case, you would think that rolling back this GPO setting would've been easily done.

 

It was many months ago, so I will just say what I recall. I recall having to place the pushprinterconnections.exe file in the appropriate GPO startup/shutdown/logon/logoff folder and I was trying to get it to work and noticed it didn't work well and caused user errors/problems, so I pulled the GPO policy and deleted the pushprinterconnections.exe. Ever since that date, every 2 hours on ALL clients on the network I get the following error:

 

"Windows failed to apply the Scripts settings. Scripts settings might have its own log file. Please click on the "More information" link."

 

THERE ARE NO STINKING SCRIPT SETTINGS TO APPLY!!! I TOOK THEM OFF, SO WHY IS IT TRYING TO APPLY THEM???? THERE IS NO "MORE INFORMATION LINK" ANYWHERE TO CLICK!! .... ALL I GET IS THIS GENERIC INFO.

 

And this "The system cannot find the file specified." leads me to think that its still looking for the pushprinterconnections.exe file at the client PC's, because I do not know what other file it would be looking for and I experimented with no other file... except perhaps a logon script (which was removed as well).

 

Once I have removed this error I'd like to continue to try to deploy printers "per workstation locale", but I will not add insult to injury and mix things up till I can get rid of this generic error which I know surfaced when I was experimenting with the pushprinterconnections.exe file.

 

Lastly, is there some way to "step through" the GPO's as they are applied on the server? Where should I look to see what the server is doing with the GPO's to get more details on this problem? I have looked at the report of GPO's applied to the network and there ARE NO SCRIPT GPO's in effect.

 

Event log output below which repeats every 2 hours on all client PC's. HELP!!!

 

Log Name:      System
Source:        Microsoft-Windows-GroupPolicy
Date:          8/25/2014 1:03:49 AM
Event ID:      1085
Task Category: None
Level:         Warning
Keywords:      
User:          Domain\user
Computer:      ITADMIN.domain.local
Description:
Windows failed to apply the Scripts settings. Scripts settings might have its own log file. Please click on the "More information" link.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-GroupPolicy" Guid="{AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}" />
    <EventID>1085</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>0</Task>
    <Opcode>1</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2014-08-25T06:03:49.906415300Z" />
    <EventRecordID>108569</EventRecordID>
    <Correlation ActivityID="{EC2D56F4-46DE-4B46-83D3-0AE4D82624CB}" />
    <Execution ProcessID="508" ThreadID="3792" />
    <Channel>System</Channel>
    <Computer>itadmin.domain.local</Computer>
    <Security UserID="S-1-5-21-299520475-1283141277-515178626-1124" />
  </System>
  <EventData>
    <Data Name="SupportInfo1">1</Data>
    <Data Name="SupportInfo2">3961</Data>
    <Data Name="ProcessingMode">0</Data>
    <Data Name="ProcessingTimeInMilliseconds">1263</Data>
    <Data Name="ErrorCode">2</Data>
    <Data Name="ErrorDescription">The system cannot find the file specified. </Data>
    <Data Name="DCName">\\ADServer.domain.local</Data>
    <Data Name="ExtensionName">Scripts</Data>
    <Data Name="ExtensionId">{42B5FAAE-6536-11d2-AE5A-0000F87571E3}</Data>
  </EventData>
</Event>



BC AdBot (Login to Remove)

 


#2 JohnnyJammer

JohnnyJammer

  • Members
  • 1,117 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:QLD Australia
  • Local time:04:35 AM

Posted 25 August 2014 - 07:49 PM

when ever i trouble shoot GPo settings i always gpupdate /force and then use rsop.msc command and run that both as administrator and also a common user.

Then check for any little yellow question marks and it should say what the error is.

 

To find the culpurate check the process ID because it details it here <Execution ProcessID="508" ThreadID="3792" />, either use taskmgr.msc or processexplorer from sysinternals suite.


Edited by JohnnyJammer, 25 August 2014 - 07:50 PM.


#3 searcherrr

searcherrr
  • Topic Starter

  • Members
  • 5 posts
  • OFFLINE
  •  
  • Local time:01:35 PM

Posted 26 August 2014 - 11:00 AM

Thanks Johnny.

 

I did what you said and I was able to trace the 508 to Windows Management Instrumentation (or winmgmt running in the netsvcs group according to task manager).

 

When I looked at the resultant set of policy under user configuration there is the 1 ! mark (no other errors anywhere except here at "SCRIPTS") and when I drilled down to SCRIPTS after RIGHT CLICKING "user configuration" the most basic error in the world is shown yet again:

 

Tuesday, August 26, 2014 9:42:15 AM
Scripts failed due to the error listed below.
The system cannot find the file specified.
 

WHAT FILE SPECIFIED? WHERE????? HOW CAN I TELL WHAT FILE ITS LOOKING FOR? SHOULD I PUT THE PUSHPRINTERCONNECTIONS.EXE FILE BACK IN PLACE IN THE LOGON PORTION OF THE GPO AND REAPPLY??? THEN REMOVE IT AGAIN??

 

WHERE DO I LOOK TO SEE WHAT FILE IS SPECIFIED? LOL :smash:



#4 JohnnyJammer

JohnnyJammer

  • Members
  • 1,117 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:QLD Australia
  • Local time:04:35 AM

Posted 27 August 2014 - 07:00 PM

Its odviously looking for a file some where lol, i hate issues like this tryign to trouble shoot. In the user config/scripts/logon just remove them login scripts (If any is there) but dont delete them, just remove from the listbox display.

Then from the server issue the command

wmic /node:nameofcomputer process call create "gpupdate /force"

See if you get that little icon again.

 

Also you shouldnt need to use pushprint when using userconfig/prefs/control panel/printers. As long as you use either the netbios name or FQDN and set the targeting to that os users in the group in side the OU then there shouldnt be an issue.

On the other hand you can stop processing that printer by selecting (Ticking) the Stop processing on the common tab of the printer.

make sure the itel level targeting is the group of users beloging to that OU or branch etc etc.

 

PS:Always create the printer and never update because the create will delete the printer then re-create it.

Alsom check to amke sure you have Point & Print isolation enabled and set to not display warnings installing drivers. Its located under Userconfig/admin templates/control panel/printers, sorry for late reply mate been busy!


Edited by JohnnyJammer, 27 August 2014 - 07:03 PM.


#5 searcherrr

searcherrr
  • Topic Starter

  • Members
  • 5 posts
  • OFFLINE
  •  
  • Local time:01:35 PM

Posted 01 May 2015 - 09:44 AM

Well to post back on th is, since August 2014, it is still happening to every computer on the network.

 

After doing some investigating of my own in the windows registry for GUID 42B5FAAE-6536-11d2-AE5A-0000F87571E3 it seems as though this is the Group Policy Extension that deploys scripts. I guess at some point when thinking I needed the pushprinterconnections.exe file to deploy printers for a Windows 7 environment I screwed up the GPE's in the registry..... because there are no scripts or exe's to deploy listed in any folder that GP looks at, but the GUID 42B5FAAE-6536-11d2-AE5A-0000F87571E3 it still listed in the GPE settings in the registry trying to deploy scripts that aren't there. So I'm going to remove the GUID 42B5FAAE-6536-11d2-AE5A-0000F87571E3 from the registy in places I think it shouldn't be for a "current deployment" and do a /force and see if that fixes things and post back.



#6 searcherrr

searcherrr
  • Topic Starter

  • Members
  • 5 posts
  • OFFLINE
  •  
  • Local time:01:35 PM

Posted 01 May 2015 - 11:06 AM

Wow. After all this time I fixed it myself. One of those things where you had to know what you were tinkering with a long time ago to fix it today.

 

Here's what I did and whether or not I have "removed" the capability for me to utilize "scripts" with GPO remains to be seen, but if I did inadvertently do so, I can just add the backup registry keys back to the registry on my AD1 server and it should restore functionality to what it was.... but ONLY IF I ACTUALLY PUT A SCRIPT in a shutdown/startup/logon/logoff folder for a GPO I need to use which currently I do not have any scripts I "NEED" to use for our network, because I like to keep it as simple as I can.

 

Here are the registry keys I modified. These are their "ORIGINAL" versions before I removed GUID 42B5FAAE-6536-11d2-AE5A-0000F87571E3 anywhere I saw it listed.

 

Registry backup key 1 - I took ownership of and entirely removed this key after backing it up:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{42B5FAAE-6536-11d2-AE5A-0000F87571E3}]
@="Scripts"
"ProcessGroupPolicy"="ProcessScriptsGroupPolicy"
"DllName"=hex(2):67,00,70,00,73,00,63,00,72,00,69,00,70,00,74,00,2e,00,64,00,\
  6c,00,6c,00,00,00
"GenerateGroupPolicy"="GenerateScriptsGroupPolicy"
"NoSlowLink"=dword:00000001
"ProcessGroupPolicyEx"="ProcessScriptsGroupPolicyEx"
"NoGPOListChanges"=dword:00000001
"NotifyLinkTransition"=dword:00000001
"DisplayName"=hex(2):40,00,67,00,70,00,73,00,63,00,72,00,69,00,70,00,74,00,2e,\
  00,64,00,6c,00,6c,00,2c,00,2d,00,31,00,00,00
 

Registry backup key 2 - I took ownership of and entirely removed this key after backing it up:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{42B5FAAE-6536-11d2-AE5A-0000F87571E3}]
@="Scripts"
"ProcessGroupPolicy"="ProcessScriptsGroupPolicy"
"DllName"=hex(2):67,00,70,00,73,00,63,00,72,00,69,00,70,00,74,00,2e,00,64,00,\
  6c,00,6c,00,00,00
"GenerateGroupPolicy"="GenerateScriptsGroupPolicy"
"NoSlowLink"=dword:00000001
"ProcessGroupPolicyEx"="ProcessScriptsGroupPolicyEx"
"NoGPOListChanges"=dword:00000001
"NotifyLinkTransition"=dword:00000001
"DisplayName"=hex(2):40,00,67,00,70,00,73,00,63,00,72,00,69,00,70,00,74,00,2e,\
  00,64,00,6c,00,6c,00,2c,00,2d,00,31,00,00,00
 

Registry backup key 3 - I took ownership of and entirely removed this key after backing it up:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\Status\GPExtensions\{42B5FAAE-6536-11d2-AE5A-0000F87571E3}]
"Status"=dword:00000002
"RsopStatus"=dword:00000000
"LastPolicyTime"=dword:011b8c5a
"PrevSlowLink"=dword:00000000
"PrevRsopLogging"=dword:00000001
"ForceRefreshFG"=dword:00000000
 

Registry backup key 4 - I entirely removed this key after backing it up:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{42B5FAAE-6536-11d2-AE5A-0000F87571E3}]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{42B5FAAE-6536-11d2-AE5A-0000F87571E3}\0]
"Options"=dword:00000000
"Version"=dword:001f001f
"DSPath"="LDAP://CN=User,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=spine,DC=local"
"FileSysPath"="\\\\spine.local\\sysvol\\spine.local\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}\\User"
"DisplayName"="Default Domain Policy"
"Extensions"="[{00000000-0000-0000-0000-000000000000}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}][{5794DAFD-BE60-433F-88A2-1A31939AC01F}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}][{8A28E2C5-8D06-49A4-A08C-632DAA493E17}{CC13E3F3-D6D7-4A7C-A806-085502AA8281}]"
"Link"="LDAP://DC=spine,DC=local"
"GPOName"="{31B2F340-016D-11D2-945F-00C04FB984F9}"
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,00,00,00,00,00
 

Registry backup key 5 - I EDITED the "Extensions" string key by removing the {42B5FAAE-6536-11d2-AE5A-0000F87571E3} after backing it up:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{5794DAFD-BE60-433f-88A2-1A31939AC01F}\0]
"Options"=dword:00000002
"Version"=dword:001f001f
"DSPath"="LDAP://CN=User,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=spine,DC=local"
"FileSysPath"="\\\\spine.local\\sysvol\\spine.local\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}\\User"
"DisplayName"="Default Domain Policy"
"Extensions"="[{00000000-0000-0000-0000-000000000000}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}][{5794DAFD-BE60-433F-88A2-1A31939AC01F}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}][{8A28E2C5-8D06-49A4-A08C-632DAA493E17}{CC13E3F3-D6D7-4A7C-A806-085502AA8281}]"
"Link"="LDAP://DC=spine,DC=local"
"GPOName"="{31B2F340-016D-11D2-945F-00C04FB984F9}"
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,00,00,00,00,00
 

Registry backup key 6 - I EDITED the "Extensions" string key by removing the {42B5FAAE-6536-11d2-AE5A-0000F87571E3} after backing it up:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{8A28E2C5-8D06-49A4-A08C-632DAA493E17}\0]
"Options"=dword:00000002
"Version"=dword:006d006d
"DSPath"="LDAP://CN=User,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=spine,DC=local"
"FileSysPath"="\\\\spine.local\\sysvol\\spine.local\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}\\User"
"DisplayName"="Default Domain Policy"
"Extensions"="[{00000000-0000-0000-0000-000000000000}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}][{5794DAFD-BE60-433F-88A2-1A31939AC01F}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}][{8A28E2C5-8D06-49A4-A08C-632DAA493E17}{CC13E3F3-D6D7-4A7C-A806-085502AA8281}]"
"Link"="LDAP://DC=spine,DC=local"
"GPOName"="{31B2F340-016D-11D2-945F-00C04FB984F9}"
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,00,00,00,00,00
 

Anywhere else (after doing a thorough and COMPLETE FIND operation in registry for scripts GUID 42B5FAAE-6536-11d2-AE5A-0000F87571E3) in the registry I found 42B5FAAE-6536-11d2-AE5A-0000F87571E3 I removed it from a string or deleted a whole key if I could see that key was related "ONLY to SCRIPTS". I just used my judgement.

 

Again, if I have removed ability to utilize scripts in GPO by doing this, I didn't mean to, but its possible I did, but easily put back in place by running the Group Policy Extension backup registry keys shown above. I suspect though, if I were to go into the Group Policy Editor gui and just select scripting again and set it up that the 42B5FAAE-6536-11d2-AE5A-0000F87571E3 guid for scripting would simply be re-added back into the registry at the appropriate time by default design of how the GP Editor works.

 

After I removed and edited those keys above on the AD1 server I did a gpupdate /force on that server and for good measure I went and did the same command on my 2 other AD servers and then 1 more time on a PC to test the newly applied settings and after all that........WA-LA!!!!! BOOOOOOMMMMMM!!!! The ____ infernal scripting error finally went away in ALL PC's on the network!!!!!!!!! HOOORRRRAAAAAAAAAAYYYYYYYYYYYY!!!!!!!! :bounce: :bananas: :guitar: :bananas: :bounce: :bananas: :bounce:



#7 25PSi

25PSi

  • Members
  • 1 posts
  • OFFLINE
  •  
  • Local time:11:35 AM

Posted 06 May 2015 - 03:59 PM

Only reason i registered to post this.

 

We happened to have same issue on 99.9% of our systems!!! 

After spending ungodly amount of time i still have no solution but i do think that i know that issue resides on the client side. 

 

GUID of {AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9} indicates GPSCRIPT.DLL It needs to be in Sys32 folder and accessible and working or Group Policy will not be able to use it to runs Scripts on the client side. Makes sense no?

Well i checked my systems and all seems to have this ancient (from 2009) DLL in the proper place. But.... if i try to un-register just so i could re-register it later it gives an error:

 

 

  • The module "gpscript.dll" was loaded but the entry-point DllRegisterServer was not found. Make sure that "gpscript.dll" is a valid DLL or OCX file and then try again.

This led me to believe that something is wrong with that particular DLL and when Group Policy try to use it, it simply can not. So.............. I think i know exactly what the issue is but i have ZERO idea how to fix it. 

 

Doing above mentioned fix will indeed disable ability to run Scripts Via. GPO and i do not think i want to do that in my environment. 

 

Mystery continues but perhaps someone can throw another rock in this pile to tip it over. 



#8 searcherrr

searcherrr
  • Topic Starter

  • Members
  • 5 posts
  • OFFLINE
  •  
  • Local time:01:35 PM

Posted 13 May 2015 - 04:48 PM

25PSi I would venture to guess that your problem (different topic slightly) exists on Windows clients prior to Windows 7 ??? If so I'd recommend obtaining the Group Policy Client Side Extensions (GPCSE) package and reinstalling them on the 32bit OS' and a HOTFIX package for those as well...... guessing that the entry point dll might be in the GPCSE package and fix your issue.

 

Another possibility, and adding to what I posted above..... I was too disgruntled to post back again...... it seems that either I didn't do all those procedures on all the AD servers or during my procedure to fix my above mentioned issue when I was working on the 1 AD server replication kicked in and all the settings I had edited and removed came back and so with it did the scripting error messages in all the client PC's.......... so........ I went back to basics...... put the thinking cap on... and this is what I did:

  1. I made an EMPTY batch file (something.bat) and plopped it inside of startup (computer) and user (logon) areas in the GP Editor and inside the something.bat file was simply a REM comment statement: IE: "REM - this is just here to be removed"
  2. I then reapplied the policy (and I don't know if this is the right way to do it, but I do a gpupdate /force on all 3 of my AD servers) starting with the 1st one I was working on where I was doing the GP Edits, then I run the same command on the other 2 successively within a few seconds of the prior one.
  3. Then I went and ran gpupdate /force on 1 client PC I was testing with.
  4. Then I went back to startup and logon respectively in the GP editor on AD server 1 and REMOVED the something.bat file and repeated #2 above, doing a /force on all AD servers again..... this time to REMOVE the something.bat scripts enforcement.
  5. Then I repeat #3 on the client test box.

Low and behold...... finally..... the d___ scripting messages have EVACUATED from the windows pc logs...... and later on I then caused other non-related havoc by experimenting further with more GP's........ THAT MIND YOU SIMPLY DON'T JUST WORK AS THEY SHOULD..... TAKING OVER CONTROL OF THE CLIENT PC'S...... NO NO NO... MUCH CONFIGURATION ON BOTH SIDES (DEFEATING THE PURPOSE OF GP INITIALLY) MUST BE DONE TO MAKE STUFF WORK RIGHT........... IE: The fact that if I want to write/copy files from a deployment folder on a server to client PC's all security ACL's and Share permissions must MUST MUST include "Domain Computers" and "Authenticated Users" with proper permission levels to write files to the destinations...... and at the source at a minimal those 2 group names must have READ access specified ...... don't forget in the "SHARE" too if you use one, and I suggest you don't use a SHARE as a source, but a hard server path instead. While this may be a little off topic, it could also be on topic if in the method of applying scripts at logon some file copying was utilized at some point in the past by some predecessor.

 

:)

 

Interested to see if you write back 25PSi. More interested to see if you fix it from what I said or in general and what the fix is/was. CHEERS!






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users