Software installation policy is processed before Startup Scripts are executed. Sometimes that's exactly what you want, and other times it's not. You can't change it.
When I want a startup script to run before software installation I end up using group membership to control the execution of the startup script and I end the startup script with a command to add the computer to a second group that controls software installation. The only problem with this is that, to date, I have yet to find any reliable way to restart a Windows XP or newer OS from a startup script. (Yes, yes-- I've tried a variety of methods, too. I can discuss them in detail if you'd like.) As such, this always makes this strategy require two boots to "take effect".
You mention "preferences", so I think you're looking at doing things to the user's environment via a logon script. Logon scripts are executed, obviously, after logon. If you're looking to check to see if a piece of software has been installed during the logon script query the Windows Installer "database" in the registry to see if the program is there and "bail out". You'll find the installed products in the "HKEY_CLASSES_ROOT\Installer\Products" key. Obviously, you'll have to figure out the GUID for the package you're dealing with.
Edit: Group Policy client-side extension (CSE) processing order is performed based on the value of the GUID for the client-side extension, from what I've been able to glean from documentation. It looks like the CSE's with numerically higher GUIDs execute later. I don't have the GUID for the "Preferences" CSE handy so I can't tell you how it should act re: running before / after other CSE's.
On Windows XP, at least, dig into HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\GPExtensions and look for the CSE for "Prefernces". REGEDIT will sort those GUIDs numerically, too, so you could be able to tell, visually, if that "Preferences" CSE is going to execute before/after other CSE's.
I can't help you with group-policy, but each extension includes its update URL in manifest.json.
So, for the current version of adblock (id: gighmmpiobklfepjocnamgkkbiglidom):
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Extensions\gighmmpiobklfepjocnamgkkbiglidom\2.5.14_0\manifest.json
Contains:
"update_url": "http://clients2.google.com/service/update2/crx"
The extension will query that URL for updates, as per the documentation.
We can therefore construct a URL that will return the update XML from the above URL (just change the ID as needed) - for adblock:
http://clients2.google.com/service/update2/crx?response=updatecheck&x=id%3Dgighmmpiobklfepjocnamgkkbiglidom%26uc
The XML that is returned reads:
<?xml version="1.0" encoding="UTF-8"?>
<gupdate xmlns="http://www.google.com/update2/response" protocol="2.0" server="prod">
<daystart elapsed_seconds="49387"/>
<app appid="gighmmpiobklfepjocnamgkkbiglidom" status="ok">
<updatecheck codebase="http://clients2.googleusercontent.com/crx/download/OAAAAFpzXu4buuGNADfzIKiz34SLARZdBLiXQ2zo50sAlzoBpEz77foH-XT3yHpPureXtHcQSYU2z4ZNstiuKJi-LD8AxlKa5VgufvySdIb5b9U333P0upRk1YPb/extension_2_5_14.crx" hash="" size="529317" status="ok" version="2.5.14"/>
</app>
</gupdate>
We are interested in the codebase attribute of updatecheck, which provides us the direct URL to the latest CRX file.
Best Answer
Currently it's not possible to turn off spell check in Chrome with group policy.
However after asking a bunch more questions on why they wanted it turned off: there is an Intranet Web application that they are developing and spell check keeps underlining peoples names and addresses in the forms. So researching on that criteria I found a way to do this with HTML. Just need to add spellcheck=false to the input tags you need to turn it off for.
(I'm not going to mark this as the answer because its not actually turning off spell check with group policy.)