---Working with Windows Nt 4.0---
Im having problems with activating Proxy in KixScript. I added the necessary lines to the current user:

WRITEVALUE ("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyHttp1.1","0x00000000","REG_DWORD")
WRITEVALUE ("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyServer","nt4:80","REG_SZ")

It seems that the network profile overrides the scriptsettings for the proxy-enable key....Does any1 know what to do with that???

Regards,

Maarten

Welcome to the board !

When you say "network profile" - are you refering to automatic configuration scripts ?

If yes - can't you just change the auto config .ins to not update these values on browser startup ?

Shawn.

I was referring to the user profiles....

But errr, with great help of my collegue we finally figured it out...I made a registry entry with Kix in the runonce on current user that calls a second script. This second script applies the correct Proxy settings, but it now applies after copying/setting up the user profile from the server, so that the user profile doesnt override the settings anymore.

So, no more probs here, but a lot more knowledge of Kix, though ...

thx anyway!

grtz,

Kreator

Before you go ...

Even though you said in your first post that your dealing with NT4 - what you meant to say was that you have NT4 servers and Win9x workstations ?

If not - and your workstations are NT - this sort of blows away and my pre-conceived notions on the ordering of the logon process...

Can you just clear this up (for me, please) ?

Shawn.

- No, i meant to say that i was working with Windows NT servers and Windows NT workstation

- Well, then blow away... What i said before worked. Only prob with that was that users are not allowed to add a regkey to the runonce in current user..
So were now in doubt here if we should continue using these scripts for proxy settings or change to policies....

Can you just clear this up (for me, please) ?

- Well....did I??

Kreator

Ok - just to verify, here's my environment (I think it's the same as yours)...

1) NT SERVERS
2) NT WORKSTATIONS
3) USERS HAVE ROAMING PROFILES
4) LOGON SCRIPT SET TO RUN SYNCHRONOUSLY

This is my notion of how the logon process works...

1) USER AUTHENTICTION
2) SERVER PROFILE COPIED TO WORKSTATION
3) WINDOWS NT POLICIES APPLIED
4) LOGON SCRIPT RUNS
5) USER GETS DESKTOP

I have never (yet) seen a logon script registry poke fail because the user's roaming profile was not loaded by the time the logon script runs...

We *have* had problems with Internet Explorer though - but for only two reasons...

1) When a user logs into a workstation for the first time - IE goes into a once only user setup mode when they start their browser for the first time, and it will tend to overwrite one's logon script pokes. These scripts are called install.ins and custom.ins (?) and are located somewhere in IE's program files location... For the next and all subsequent logons - everything is cool...

2) If internet explorer automatic configuration is enabled - the network install.ins will obviously overwrite any logon script poke *every time* the browser is started up

Can anyone verify my assumptions here ?

I'm I losing this debate and should I just go back to my hole and sulk ?

Shawn.

[This message has been edited by Shawn (edited 26 January 2001).]

To my knowledge this is the correct order with synchronous script...
1) USER AUTHENTICTION
2) LOGON SCRIPT RUNS
3) SERVER PROFILE COPIED TO WORKSTATION
4) WINDOWS NT POLICIES APPLIED
5) USER GETS DESKTOP

If A-synchonously script is set then:
1) USER AUTHENTICTION
2) SERVER PROFILE COPIED TO WORKSTATION
3) WINDOWS NT POLICIES APPLIED
4) LOGON SCRIPT RUNS
5) USER GETS DESKTOP

regards,

Maarten

With synchronous script...

1) USER AUTHENTICATION
2) SERVER PROFILE COPIED TO WORKSTATION
3) WINDOWS NT POLICIES APPLIED
4) LOGON SCRIPT RUNS
5) USER GETS DESKTOP

With asynchonous script...

1) USER AUTHENTICATION
2) SERVER PROFILE COPIED TO WORKSTATION
3) WINDOWS NT POLICIES APPLIED
4) USER GETS DESKTOP AND LOGON SCRIPT RUNS

Anyone else care to comment ?

Come on guys - lets clear this up once and for all ! I don't want to have to search the knowledge base all day to get to the bottom this... hey Roger - remember - the "truth is out there!" ...

Shawn.

[This message has been edited by Shawn (edited 26 January 2001).]

I'm going to keep searching though - the truth shall set us free !

Actually - I'm just having some fun - so if it works - it works ! I'll be the first to admit that you can't argue with something that works !

Kix on, my Brother !

Shawn.

[This message has been edited by Shawn (edited 26 January 2001).]

Bryce

[This message has been edited by Bryce (edited 26 January 2001).]

user policy...

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

RunLogonScriptSync = 1 (DWORD)

machine policy...

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

RunLogonScriptSync = 1 (DWORD)

Shawn.

Here's an excellent Microsoft document for anybody that's involved with Win9x and WinNT policies and profiles (deployment and administration)...

Implementing Profiles and Policies for Windows NT 4.0

The interest bits are on pages 84 to 89

This is the best darn logon process overview I've ever seen (but then again - this is the *only* one I've ever seen)

It very detailed but there is NO mention of the logon script - I imagine this is because it isn't executed this early on !

Anyway - just an FYI - but very informative ...

Shawn.

If been searching the www like crazy so I could reply with this line

Ok, I have to agree with Shawn on this one.
Why? Elimentary my dear Watson...

Have you ever had the message: Your locally stored profile is newer than your roaming profile. Would you like to use the local profile? [Yes] [No]

Have you ever seen the Kixtart DOS-box before or during this message?

And therefore the butler did it in the kitchen with the candleholder.

------------------
Greetz,

Roger the Young
------------------------
The code is out there...
------------------------

http://home.wanadoo.nl/r.s.m.s.dejong/Kixtart

------------------------

Oh God - I'm going home - it's Friday !

Marten:

I just can't help but think there's something we're missing here - some difference between our domains that's causing this... hmmm...

Shawn.

[This message has been edited by Shawn (edited 26 January 2001).]

We probably got a little side-tracked there - sorry 'bout that...

If you still want to get to the root of this problem - maybe we should go back to the basics...

For example, you might want to capture and display the return codes from your failing scripts...

code:

---

$rs = WRITEVALUE("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyHttp1.1","0","REG_DWORD")

?"error: @serror (@error)"

---

If the profile if not there - I would imagine that any write to it would fail ???

As well, you should probably use "0" instead of "0x00000000" in your writevalue() - kix doesn't really do the kex conversion (it just seems to work because it defaults to zero, for example 0x00000020 doesn't work).

Hope to be of assistance...

Shawn.

[This message has been edited by Shawn (edited 27 January 2001).]