none
GPO Login scrip location

    Question

  • Hi

    I want to use netsh wlan to import wireless profiles (we actually, I just want the password added as I have the wireless lan defined in a GPO).  but I need to provide a path to where the profile is kept

    My thought was to create a login script that basically ran this command

    netsh wlan add profile filename=LocationOfFile\WIRELESS.xml

    But I am not sure where the location is. Seems a bit silly have to create a fileshare for people to be able to read this

    can I just use .\ ?

    My thoughts are like this

    Use a gpo to install the Wireless config

    Use a login script to install the wireless profile (re install the above) with password.

    The reason I want the gpo is the wireless profile can't be deleted by the user it will always be there.  I only have PSK setup on the wireless - thus the reason for the script.

    My understanding of the netsh wlan add profile is one of the parameters is filename this i had presumed would include a path. I had planned on installing the profiles with the scripts that way they get replicated around the DC and i don't have to manage another network share etc etc.

    So my question is can I presume the current working directory of the running script is the path where the script is and if that is true then i can use the .\ to signify the current directory.

    If its not true how do I find the path to where the script is installed.

    Are you saying I can conceal the password somehow ?

    Thanks

    Tuesday, November 20, 2012 11:20 PM

Answers

  • So my question is can I presume the current working directory of the running script is the path where the script is and if that is true then i can use the .\ to signify the current directory.

    Hope I get you right? One of your questions is about current directory vs. parent folder...
    current directory is the current path when the script has been run - or where a shortcut to the script lies - or the working directory specified in the shortcut. This is not necessarily the same folder which contains the script.

    By .\ the file example.txt is in the current directory: .\example.txt


    parent folder:
    This is in the same folder where the script is:

              function Get-ScriptDirectory
              {
              $Invocation = (Get-Variable MyInvocation -Scope 1).Value
              Split-Path $Invocation.MyCommand.Path
              }
              $MyVar = Get-ScriptDirectory

              notepad $MyVar\example.txt

    Lg
    Marcello




    • Edited by Marcello Rungi Thursday, November 22, 2012 12:07 AM
    • Marked as answer by Alex Samad Thursday, November 22, 2012 7:40 PM
    Wednesday, November 21, 2012 5:00 PM

All replies

  • The GPO login script is managed by GP and resides on all of the domain controllers.  It is replicated and managed by Active Directory.  You should not try to change this.


    ¯\_(ツ)_/¯


    • Edited by jrv Wednesday, November 21, 2012 12:04 AM
    Wednesday, November 21, 2012 12:03 AM
  • Yes I understand that .  That wasn't my question..

    Simply put.. if I want to run a login script 

    netsh wlan add profile filename=<SOME FILENAME>

    how do I address <some filename>, what is its path, can I find in the script (presume CMD), can I presume that the scripts CWD is where this <SOME FILENAME> is.

    This is based on the fact that the GPO will have 2 files in there 1 the script 2 the xml file.

    Wednesday, November 21, 2012 12:06 AM
  • That has nothing to do with a GPO.

    Where did you export it to?  It is where ever you exported it.

    This is not a scriping issue.  You need to post this kind of question in teh networking or platform forums. Your question is about how to use a configuration utility and not about how to write a script.


    ¯\_(ツ)_/¯

    Wednesday, November 21, 2012 4:11 AM
  • the guys in directory services told me to come here.

    My question is not about how to use netsh!!!!

    its very basic.  a login script that is initiated as a login script from a GPO, what is its CWD ?

    Wednesday, November 21, 2012 5:21 AM
  • the guys in directory services told me to come here.

    My question is not about how to use netsh!!!!

    its very basic.  a login script that is initiated as a login script from a GPO, what is its CWD ?

    Why didn't you just ask that question.

    It current directory is the users hoe which is usually %userprofile%.

    Note that the WLAN profile has nothing to do with the users Windows profile. It is an XML config file that is exported from NetSH and used to create a copy of the WLAN profile on another machine. 

    Go and read the WLAN NetSH documentation very carefully and you will see what it is and how it can be used.  I know of no way it can be used from a logoin script to establish a lan  connection which is why you will not find any references to that if you do a search.

    A WLAN profile is a profile of a connection.  It is an exported copy of the configuration of that connection which is also called a "connection profile".  TO copy this you export it from opne machine and import it into another or use it as a backup.

    Note that .\ is the same as current directory. YU can never rely on a login script to have a specific directory.  It may by in WIndows and it may be in the profile.  It can be somewhere else.  In login scripts it is usual to use complete paths for all file references.

     


    ¯\_(ツ)_/¯

    Wednesday, November 21, 2012 5:34 AM
  • WTF ... maybe read my original post. I was talking about the netsh wlan profile ....

    and I was going to store it with the login script !  I just needed to know how to get to the directory whilst the login script is running 

    Not sure where you got the idea I want the windows profile 

    Wednesday, November 21, 2012 5:42 AM
  • WTF ... maybe read my original post. I was talking about the netsh wlan profile ....

    and I was going to store it with the login script !  I just needed to know how to get to the directory whilst the login script is running 

    Not sure where you got the idea I want the windows profile 

    YOu cannot store anything with the login script. It is not on the userws machine.  Thej login script runs fromn teh netwrok.  It is part of Active Directory.  Storing thisng there is not allowed asz it can corrupt and compromise AD. 

    Loading a wlan profile is done once.  It is not needed to be done with AD or with a login script.  Just send the user a batch file with the XML file and have them execute the batch once.  That is all you need to do.

    As for my confusuon - reading your request again is still very confusing.  It jumps all over.  YOu ask parts of many questions and are attempting to explain your reaoning for doing things.  SOmewhere buried in al of that is a request for teh current directly of the login script.  The answer is you cannot assume the current directory.  It is pointed to many places at different times.  You must use a full path to any file you specifiy or your scriupt will not run reliably.

    Try to not give too much unrealted information.  Remeber the people here are all volunteers and may not have time to decode what you are writing.


    ¯\_(ツ)_/¯

    Wednesday, November 21, 2012 5:56 AM
  • True, some time do have the tendency to jump around the place,

    I am a bit dobious about your statement you can't store files in the gpo. can you explain to me why ad treats script files, which are text files and differently than xml files.

    Just to clear, I have borrowed somebody else walk through on adding scripts (login/logout) to GPO

    http://www.petri.co.il/setting-up-logon-script-through-gpo-windows-server-2008.htm

    You will notice they use the gpo editor and do a show files, which show the current location of that gpo on that DC.  Your suggesting that AD looks at the files, works out if they are cmd / vbscript or some sort of script and if they are not it corrupts itself ?  That would be something new.

    as for why i want to do it in the GPO and possibly do it more times than it is needed. I have stupid users, some of them change things delete things corrupt things. The slight over head of resetting the password when they login is not a beggie to me. They login maybe 1-2 a week, the rest of the time they hibernate.

    My presumption and I think a valid one is all process have a CWD where they are run from . The Login process of a windows machine grabs the gpos and executes them. It must grab the login script from some who. I am wondering if that process also set a env variable . you used to be able to us %0.  Or from memory there used to be an env variable that would point to your netlogon server (old days) so you could access that and not some predefined one in the script.

    If you can expand on the corruption side of things that would be help .

    Wednesday, November 21, 2012 7:22 AM
  • Start by studying how AD stages GPOs.  They are stored in AD and on a share. The share tthey are stored on is replicated.

    A GPO is not intended to be a private storage location for files.  Items that are not natively defined for GP and AD may not be handled correctly.

    Ask yourself where these things are stored, why they are stored and managed the way they are and how GP is distributed throughout a domain and all of its DCs whcich couldnumber in the dozens or even hundreds.

    A file can be read by the login process (userinit.exe) and executed.  The source of teh file will not be retained and should not be assumed.  Review the full login process and how it and GP are applied.  GP is applied by many processes.  It is an extensible system.  Each process can have its own working environment that is different from all other processes.

    Study the contents of all of teh pages of an RSOP report of an applied policy.  Look at how many GP processes are executed.  YOu will begin to understand the compllexity of the login and how GP does its magic.

    Many users who have not beentrained in teh internal of QWIndows or Active Directory attempt to use AD and GP to do one-off tasks becuse it seems so convenient.  I would like to warn you about doing this as it can have adverse effects.  Reapplying the same complex configuration over and over again is not ususally a good idea.  If you review GP you will see that the policies that are defined arre nearly always mediated by a process that is designed to apply and maintain that policy.  Using a login scrips as a policy engine is really a misuse of the login script.  The definition and recommendations for login scritps is that they should be simple and handle specific simple things and not be used as a way to expand on WIndows functionality.

    All of that said - all of life is a set of choices - choices need to be made based on a complete understanding of the context and impact of the choice.  If you feel you have the simplest solution then  apply it.  It may work but it may not.  My recommendation is to not do complex configurations in a login script.  You are free to experiment if you really think you understand what is happening.  You can always undo what you have done.  Be sure to test.

    I think you will find that using a login script will not be very reliable and you might find that using AD as a file share can cause unpredictiable things to happen.  In a small network this will probably not be a big issue although it may be hard to troubleshoot if an issue turns up a year from now.  After all, who but you would ever imagine that a configuration file would be stored where we normally store login scripts.  It is a problem that might never be found.

    When configuring a network it is always the best practice to not deviate from standard practices and documented methods.

    Good Luck


    ¯\_(ツ)_/¯

    Wednesday, November 21, 2012 9:05 AM
  • Do you know how they are distributed..  My last read was it was a mechanism similar to DFS... Most of the files in there are XML's (have a look at  drive mapping)

    As for repeating complex ... creating a wireless profile isn't that complex. And I would have to disagree computer are very good at doing repedative tasks. They do it very well.  I think also your assumption that placing text files in this location %SystemRoot%\SYSVOL\sysvol\<domain DNS name>\Policies\{GUID}\User\Scripts\Logon is going to corrupt AD.

    Just because there are lots of task doesn't make it complex...

    Scripts are the perfect place to do complex task. That way you can reproduce the same results time and time again...

    Any way this has digresses into what I would consider to not be best practice discussion, I'm sorry but the only thing I can agree on is testing and backing up.

    I had hoped to get a quick answer to a simple question, it could be i worded it wrongly. I was thinking maybe I should have asked what environment variables are available to logon scripts.

    I am just going to write a script to find out this info.

    edit:

    For others who might be interested

    i found this

    http://social.technet.microsoft.com/Forums/en/winserverGP/thread/3615fa33-f878-45f8-af58-4e6c9391cf2d

    forgot I could use \\domain\sysvol ! and the guid is fixed !

    also found this

    http://blog.chrisara.com.au/2011/08/emulating-logonserver-for-computer.html

    seems like %0 is still set to the location the script is at.

    off to do some testing 


    • Edited by Alex Samad Wednesday, November 21, 2012 9:41 AM
    Wednesday, November 21, 2012 9:20 AM
  • Sorry but you will have to pursue this on your own.  CLearly youy have not understood how this works (AD and GP) .  XML file are not just text files and are intimately connected with AD.  They are not just any file.

    As you proceed withthis you will begin to discover what I am outlining.  It will all become clear.


    ¯\_(ツ)_/¯

    Wednesday, November 21, 2012 10:07 AM
  • LOl.. most of the XML gpo files I have looked at are just text files..

    I think you are mixing up how they are used to what the data is...

    XML -> http://en.wikipedia.org/wiki/XML  even ms followed these standards... key point human readable.

    Sorry I have to diss agree with most of your suggestion. 

    I think you will find a lot of people (in these forums suggest editing those xml files ) 

    http://social.technet.microsoft.com/Forums/en/winserverpowershell/thread/cb2ac95f-cbaf-40f1-8f6e-6de10ac5fa02 as an example.  Not saying that proves it but I am not find any that say not to.

    And the whole concept of placing a file in this directory 

    %SystemRoot%\SYSVOL\sysvol\<domain DNS name>\Policies\{GUID}\User\Scripts\Logon

    corrupting AD .. that just plan wrong...

    But partly because of MS lack of document every thing :) people will dissagree

    Wednesday, November 21, 2012 10:28 AM
  • GPOs are stored i two places.  They are added to SYSVOL and also in AD.  GPOs aer integrated with AD they ar not just files.

    The fact that a file is a text, data, XML r other type of file has nothing to do with what we are discussing.  A database is just a binary structured file but that does not mean you can store data in it with a binary editor.

    Do what you like.

    The documentation is there.  You need to review the technical documentation on Actibve Directory and how GPOs are stored and deployed.  As someone who is certified in Active Directory.


    ¯\_(ツ)_/¯

    Wednesday, November 21, 2012 4:59 PM
  • So my question is can I presume the current working directory of the running script is the path where the script is and if that is true then i can use the .\ to signify the current directory.

    Hope I get you right? One of your questions is about current directory vs. parent folder...
    current directory is the current path when the script has been run - or where a shortcut to the script lies - or the working directory specified in the shortcut. This is not necessarily the same folder which contains the script.

    By .\ the file example.txt is in the current directory: .\example.txt


    parent folder:
    This is in the same folder where the script is:

              function Get-ScriptDirectory
              {
              $Invocation = (Get-Variable MyInvocation -Scope 1).Value
              Split-Path $Invocation.MyCommand.Path
              }
              $MyVar = Get-ScriptDirectory

              notepad $MyVar\example.txt

    Lg
    Marcello




    • Edited by Marcello Rungi Thursday, November 22, 2012 12:07 AM
    • Marked as answer by Alex Samad Thursday, November 22, 2012 7:40 PM
    Wednesday, November 21, 2012 5:00 PM
  • To add to Marcello's info.

    .\ is current but can change due to batch calls.

    %0 is the pathname of the current batch file.  This is not a working directory it is just the path of the batch that is currently running.  With AD this can be in any number of places depending on the DC that you are connected to.

    Assume that you can use the GPO susbsytem as a private file sahre for distribution of files.  TRry it.  Don't be surprised when things do not work as expected. 

    Sometimes the best teacher is failure.


    ¯\_(ツ)_/¯

    Wednesday, November 21, 2012 5:17 PM
  • Here is a small example of what happens with Group Policy from the RSOP diagnostic reports.

    Component Name   Status   Last Process Time
    Group Policy Infrastructure      Success            11/21/2012 12:18:20 PM
    Folder Redirection      Success            9/2/2012 9:49:20 AM
    Group Policy Drive Maps      Success            9/4/2012 11:38:08 AM
    Registry      Success            9/15/2012 8:33:58 AM

    Note that the process time is very old for some policies. Ther eis nothing in the share that denotes how this done and tracked.  Note also that the amin policy structure was updated when I logged on.  A more deteiled custom report or reviewintg the GP logs would show exactly what other infrastucture compoents were actually run.  I happen to know that there is a very small loginscript which runs an updates a file I use for debugging Group Policy.  ALl other policies are only applied when the account logs into a new machine or when they are changed. ALL of this is managed by the GP engine and Active Directory.  The files on teh SYSVOL share are completely owned and managed by Active Directory. They are NOT just a bunch of files.

    These are only a small part of all of the GP components that execute to apply Group Policy.  Each is tailored specifically to its job.  The application of the policy and the component choices is mediated by Active Directory.  The SYSVOL share is only a convenient and efficiet way to distribute managed policy.  It is a custom and proprietary use of DFS and the file sharing system. It is not intended to be used by anyone for purposes other than those described by and allowed by Group Policy.

    In the end you can do anything you want to do.  Just remember what was discussed here as you build your custom creation.

    Using Group Policy to configure WLAN in Vista:

    http://technet.microsoft.com/en-us/magazine/gg266419.aspx

    Here is how to select and configure the authentication method.

    http://technet.microsoft.com/en-us/magazine/2007.04.cableguy.aspx

    The same works for WIndows 2008 and later systems.  WS2008 GP is more general but pretty much the same.


    ¯\_(ツ)_/¯

    Wednesday, November 21, 2012 5:43 PM
  • This thread has gone on further than it should have.

    I ask you to think of this scenario.

    Create a login script that does nothing like

    @ECHO OFF

    REM Nothing done here

    Open GPO editor, go the gpo for logon and logout script. 

    Click the show file button - which opens windows explorer into the sysvol directory tree, copy (or ) move this script into the folder.  At this point your advise is my AD could possible be corrupted...

    Go back to the gpo and now select the file to be a logon script ...

    At this point it is okay...

    leave it for a while , let it replicate around your DC's

    Everything is still as it is... Now go back into you gpo editor back to the same gpo remove the script from the list of script to run at logon .... but leave it in the folder

    Your advise is that this will corrupt AD.  Your suggesting that Windows looks at the file thats in this sysvol, verify that it is not being used by the logon script process and for some unknown reason corrupt itself.

    Maybe thing about this, place 3 files in there, 1 a logon script, 1 a logoff script and 1 a library script that is called by the other 2.  Will this corrupt AD....  How will AD know that the 3rd file is being used by the other 2 ?

    I will accept if you add the wrong thing in the wrong place you could corrupt AD, but if you check most of the XML (and I say most cause I have only looked at a few and read only a few thread) where AD stores its config as a XML file, which are text editor readable. In some places text editor editable... Think of it like the windows registry some times you have to go there to make changes....


    Thursday, November 22, 2012 7:50 PM
  • I said that putting arbitrary files on 5teh sysvol share as a conveninet place to store dat aand configuration files was against the riules.  I did not say that putting scritps inthis l;ocatin was wrong.

    Please spend some time learning how GP and AD work and how they work to create and manage SYSVOL and its subbits.

    Much of GP is stored in AD.  If you inspect teh containers in AD yo willse the artributes that store many of the remaining bits of GP.  SYSVOL is used as a convenience and is proprietarty to AD and GP.  Microsoft can and does make changes to this structure.  Placing un expected files here may cause issues particularly if Microsoft decides to make changes.  One change that I believe is likely and soon is to remove SYSVOL in favor of a distributed service.  Use of the location to store private files could cause issues.

    YU may alos find issues if you run any of teh diiagnostics for AD and GP if teh files found are not expected. Currently only script files are assumed to reside in this location.  An XML file of arbitrary format is not a script file.  I would store it in this location.  Even  Microsoft stores support files for Software Distribution and initialization in other locatiosn and these things are specified in GP as being used by GP just like your XML file.  Software Distributoin requires a share that is NOT on SYSVOL and one that is set up correctly.

    Note also that Microsoft is very touchy about adding files to SYSVOL as unexpected files can disrupt replication via DFS or DFSR.

    AD dfoesn not store its data as XML.  AD data is in a proprietary database.  The XML fiule you are taking about is the one used to install AD.

    XML is not used by AD or GP except to store menus and templates.  The actualy work files are policy files that the XML files are used to generate.  The ADMX files are used to display the GPEdit values.  Editiong thise generates a policy file (I think it is .pol).  The policy files are used by the GP engine to apply policy.  Plain XML files are not every part of this.

    Believe me. When Microsoft defines something to beused a specific way you should not repurpose it for conveniens.  Inmy experience this is the cause a a great percentage of hard to trouble shoot failures.

    Besides - there is no need to do what you are proposing.  The filesystem is designed to store files for general purpose use and access.  WHay is ti so hard to use like anyone else.


    ¯\_(ツ)_/¯


    • Edited by jrv Thursday, November 22, 2012 11:15 PM
    Thursday, November 22, 2012 11:09 PM
  • I really didn't want to spend any more time on this, but i did happen to come across this article from microsoft whilst I was investigating something else

    http://www.microsoft.com/en-us/download/confirmation.aspx?id=580

    basically it talks about the chnage from ntfrs to dfs for the replication of sysvol (where the ad is stored on disk), interestingly they talk about using the same DFS that is used to replicate normal file system....  So there is nothing special about the DFS that is being used.

    Any way I have my plan text file in my gpo and I haven't had any issues i used ./ to reference the file the script and the data file are in the same directory.


    Tuesday, January 15, 2013 12:05 AM