Hello,
This is my first post to the group. NSIS will be one of my main assigned duties at work.
I've always been a good programmer in many different computer languages for many years. So, I have a fairly good grasp of the NSIS User Manual.
I'm at the stage now where I would like NSIS examples on how to do common things not well documented on the Internet!
(Yes, I have searched the Internet but have been unable to solve my current problem which is probably trivial to everyone here.)
Question: I know that commands such as "WriteRegStr" and "ReadRegStr" can be used with the Windows Registery. My question is how can I do a similar things with Group Policy.
I have inherited my company's NSIS script. We want to automate Group Policy updates of strings. (Currently, for other Group Policy Updates, the script uses "gpupdate /force".)
Thank you,
Newbe
Examples Please: How to Do Something like WriteRegStr with Group Policy
25 posts
It is really unclear to me what you actually want to do. If you want to write to the registry on the local machine, use WriteRegStr. If you want to push settings out to all machines on a domain, why are you not just using the tools Microsoft provides for managing domains?
Thanks for replying so quickly!Originally Posted by Anders View PostIt is really unclear to me what you actually want to do. If you want to write to the registry on the local machine, use WriteRegStr. If you want to push settings out to all machines on a domain, why are you not just using the tools Microsoft provides for managing domains?
I apologize. I do not want to write to the registry. I guess I am still unfamiliar with the topic! I certainly messed up my first question to the group.
Let me try again!
Currently, my employer has a libray file that has a NSIS header script to update Group Policy for our computers. (I don't know if if we've ever used it.) This script simply copies files and then uses 'ExecWait "gpupdate /force"'. Again, I don't know if it works at all.
Anyway, the way I understand it my first task is to develop a NSIS script to be able to automate Group Policy updates. We find going to every computer and doing "gpedit.msc" isn't easy for us.
What should I do?
Do you have several simple but complete examples of how to change "Group Policy" with NSIS. What kind of things can I do. What kind of things can't I do. What cautions should I be aware of and take.
Do you have a good .nsi header file that does many of the things I would need to do to "Group Policy". It has to be well documented. Do you also have any complete examples of how to use it.
Thank you,
I a domain environment you would set the policy on the domain controller with the tools Microsoft provide and they will be pushed out to the clients.
Most of the changes you make with the local policy editor just ends up as changes in the registry. https://www.microsoft.com/en-us/down....aspx?id=25250 lists most of the registry keys used IIRC or you could use Process Monitor to see which changes gpedit.msc makes to a system...
Example:
Most of the changes you make with the local policy editor just ends up as changes in the registry. https://www.microsoft.com/en-us/down....aspx?id=25250 lists most of the registry keys used IIRC or you could use Process Monitor to see which changes gpedit.msc makes to a system...
Example:
RequestExecutionLevel adminThis is not necessary the right way to do things, in a domain environment you should use ActiveDirectory etc.
OutFile setpol.exe
Section
WriteRegDword HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Attachments" "ScanWithAntiVirus" 3
ExecWait '"gpupdate" /force'
SectionEnd
Are you saying that I can make a lot of Group Policy changes by just updating the Windows Registry. What can you tell me to help me do this at work since this is what I probably will be forced to do. Can you elaborate as much as you can on this topic. Basically, can you steer me in the right direction and help get me started.Originally Posted by Anders View PostI a domain environment you would set the policy on the domain controller with the tools Microsoft provide and they will be pushed out to the clients.
Most of the changes you make with the local policy editor just ends up as changes in the registry. https://www.microsoft.com/en-us/down....aspx?id=25250 lists most of the registry keys used IIRC or you could use Process Monitor to see which changes gpedit.msc makes to a system...
Example:
RequestExecutionLevel adminThis is not necessary the right way to do things, in a domain environment you should use ActiveDirectory etc.
OutFile setpol.exe
Section
WriteRegDword HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Attachments" "ScanWithAntiVirus" 3
ExecWait '"gpupdate" /force'
SectionEnd
What kind of direct changes can I make to the Group Policy with NSIS? What are my limitations and why. Any examples would be appreciated.
Could you elaborate on the material that I should be studying in order to accomplish any assigned Group Policy task.
Do you have any specific Internet sites and/or book titles that will enlighten me. What should I be looking for in the descriptions of these sites and books.
In addition, I don't know anything about Active Directory, but am willing to learn. (Please forgive me if I state anything wrong as I learn how to use it.) In my situation, are you in favor of me doing everthing with Active Directory instead of NSIS? Again, do you have any references for me, either Internet or book topics.
In the context of my work and my experience, what is a "domain environment."
Basically, how do I become successful.
Thank you,
Can you elaborate on this. When I last used perfmon.exe, it offerred me information on about 10s if not a 100 variables over time.Originally Posted by Anders View Postyou could use Process Monitor to see which changes gpedit.msc makes to a system
I also think that "Group Policy" touches on many things not clearly visible with perfmon.exe. I.E.: perfom may not always be useful.
Thank you,
Again using NSIS, what are all the things I can do within Windows "Group Policy."
A quick search reveals that one commonly employed method is to set up GP on one machine and then simply copy the contents of System32\GroupPolicy over to other machines. This is GP 'cloning' rather than updating and I don't know if it's suitable for your purposes. Just something to consider, and it takes a very simple script.
Edit: If you're doing this make sure you include target OS check (WinVer.nsh) because it's not a good idea to blindly extract files. If there are different OSes across your target machines, you'll need different sets of files (again, not a difficult thing to script).
Edit: If you're doing this make sure you include target OS check (WinVer.nsh) because it's not a good idea to blindly extract files. If there are different OSes across your target machines, you'll need different sets of files (again, not a difficult thing to script).
Why are you talking about perfmon? Download Process Monitor, start procmon.exe and set it to only display registry operations. Optionally set a filter: include path contains "policy" and then use gpedit.Originally Posted by Michael18 View PostCan you elaborate on this. When I last used perfmon.exe, it offerred me information on about 10s if not a 100 variables over time.
I also think that "Group Policy" touches on many things not clearly visible with perfmon.exe. I.E.: perfom may not always be useful.
This forum is not the right place to learn about active directory. You should ask your IT staff if they have a domain controller and if the users machines are joined to this domain. If they are then use the tools Microsoft provides...
What operating systems are covered by WinVer.h, and what does the following link mean by obsolete. Is there something else besides WinVer.h?Originally Posted by aerDNA View PostIf you're doing this make sure you include target OS check (WinVer.nsh) because it's not a good idea to blindly extract files. If there are different OSes across your target machines, you'll need different sets of files (again, not a difficult thing to script).
Thank you,
Just use NSIS 3.0b1, it supports Win versions up to 8.1/2012R2 out of the box. WinVer.nsh contains usage documentation and examples. Also, to write to System32 on x64 you need ${DisableX64FSRedirection} (x64.nsh). And don't forget RequestExecutionLevel Admin.
Is the following the correct way to use "DisableX64FSRedirection":Originally Posted by aerDNA View PostJust use NSIS 3.0b1, it supports Win versions up to 8.1/2012R2 out of the box. WinVer.nsh contains usage documentation and examples. Also, to write to System32 on x64 you need ${DisableX64FSRedirection} (x64.nsh). And don't forget RequestExecutionLevel Admin.
Function .onInitWhere can I get a copy of the correct "WinVer.nsh". Or, are they all the same.
${If} ${RunningX64}
${DisableX64FSRedirection}
;...
${EnableX64FSRedirection}
${EndIf}
FunctionEnd
Eg: nsis.sourceforge.net/Include/WinVer.nsh
Thank you,
Are there different ways to run "gpupdate". Why is that.
----------------------- From Below Reference -----------------------------------------
1. Exec: Plainly execute the called string, be it some application, console or file.
2. ExecWait: Executes like Exec but waits till the process exits.
...
5. nsExec::ExecToLog: The documentation says ExecToLog is similar to plain nsExec but it outputs to log window. What does that mean, what is a log window?
...
7. ExecDos: Same as nsExec::ExecToStack but it additionally (Is it not?)
a. takes string parameter that serves as stdin for running application.
b. works in both sync/async mode.
c. it works out of section - for .onInit check outs.
Reference:
Thank you,
----------------------- From Below Reference -----------------------------------------
1. Exec: Plainly execute the called string, be it some application, console or file.
2. ExecWait: Executes like Exec but waits till the process exits.
...
5. nsExec::ExecToLog: The documentation says ExecToLog is similar to plain nsExec but it outputs to log window. What does that mean, what is a log window?
...
7. ExecDos: Same as nsExec::ExecToStack but it additionally (Is it not?)
a. takes string parameter that serves as stdin for running application.
b. works in both sync/async mode.
c. it works out of section - for .onInit check outs.
Reference:
Thank you,
What are the steps to copy the contents of System32\GroupPolicy from one computer over to another computer.Originally Posted by aerDNA View PostA quick search reveals that one commonly employed method is to set up GP on one machine and then simply copy the contents of System32\GroupPolicy over to other machines.
I know that I can use a CD to help accomplish this! My idea is that the CD would hold the contents of System32\GroupPolicy on one computer. I would then use NSIS to copy the CD contents to a second computer.
But, my question is. Is there a better way to do the copy. In other words does NSIS have an instruction to help automate this procedure.
Do you have any suggestions.
Thank you,
No need for CD, files can be packed inside the installer. Include/extract files with File instruction.
Great, so now I need a way to distinguish one computer from all the remaining computers.Originally Posted by aerDNA View PostNo need for CD, files can be packed inside the installer. Include/extract files with File instruction.
(I want to use only one installer.)
What I mean is I would manually update group policy on one machine ,and I would not run "gpupdate /force" on that machine. I would run "gpupdate /force" on all the other machines to obtain new Group Policies.
Question: With an "if" statement, how do I distinguish the machine where I do Group Policy manually from all the other machines?
Thank you,
Have you familiarized yourself with the way File instruction works? You should be compiling the installer on the 'source' machine (or anywhere as long as you provide the files) and running it on target machines. No need to distinguish between anything.
SetOutPath $SYSDIR\GroupPolicy # dir to extract files to (target machine, runtime)
File /r "C:\WINDOWS\System32\GroupPolicy\*.*" # dir to pack files from (source machine, compile time); extracted to above location at runtime
Originally Posted by aerDNA View PostHave you familiarized yourself with the way File instruction works? You should be compiling the installer on the 'source' machine (or anywhere as long as you provide the files) and running it on target machines. No need to distinguish between anything.
SetOutPath $SYSDIR\GroupPolicy # dir to extract files to (target machine, runtime)
File /r "C:\WINDOWS\System32\GroupPolicy\*.*" # dir to pack files from (source machine, compile time); extracted to above location at runtime
I have what I know is a stupid question that I have got to ask because I'm confused! Basically, I don't know how to run the "file" command on two computers using the same installer.
Some minor details:
First, my NSIS compiler lives on a computer (call it S1 for this discussion) that has Group Policy values which are not associated with what I want to do with the launcher that I create on S1.
Second, I can put the NSIS compiler on another computer (call it S2) which has the baseline Group Policy settings that I want to distribute to a hundred other computers.
Embarrassed,
Thank you,
What do you mean by same installer? If you're looking to update all machines simultaneously with one instance, this is not the way to do it. For the method we're discussing, compiled exe needs to be executed on each machine. I figured you understood that since you had that CD idea.
"hundred other computers"... you better make perfectly sure you're doing this the right way, otherwise it may end up costing you your job.
"hundred other computers"... you better make perfectly sure you're doing this the right way, otherwise it may end up costing you your job.
Yes, after compiling the NSIS script and putting it on a CD, I will take it to each computer and run the script there.Originally Posted by aerDNA View PostWhat do you mean by same installer? If you're looking to update all machines simultaneously with one instance, this is not the way to do it. For the method we're discussing, compiled exe needs to be executed on each machine. I figured you understood that since you had that CD idea.
"hundred other computers"... you better make perfectly sure you're doing this the right way, otherwise it may end up costing you your job.
So, I'm still confused about the details on how to use the NSIS "file" command to store the "Group Policy" files with the installer, and then how to use the "file" command to use the stored "Group Policy" files.
How many scripts will I have to compile. Is it: 1 to store the "Group Policy" files via the "file" command, and a 2nd one to use the "file" command to unpack the stored "Group Policy" files. I was thinking that if I had a way to distinguish specific computers in the script then I could easily use two versions of the file command.
Maybe, I should be asking for the detailed steps that I should follow.
I'm perfectly willing to forget the "file" command and just use one compiled NSIS script to copy the desired "Group Policy" files (which can be saved to a CD) to each of the 100 computers that I'm working with.
I got lost when you suggested that I use the "file" command.
One option to use only 1 script, would be to manually put the number 0 in a file on the CD (call the file flag), and having the script read the file and do one thing (pack up the Group Policy files into the installer) when it sees the 0 and write 1 to that same file, but if the script reads the file and sees a 1 it could unpack the "Group Policy" files from the installer.
Anyway, can you explain via baby steps (in detail) of how to use the "file" command on two computers and the number of NSIS scripts involved.
Currently, my only viable option is to copy the Group Policy files to a CD and copy them to each computer.
Thank you,
You only need a single script, compiled once. Sure you can use CopyFiles instead of File but there's no reason for it; it doesn't make things simpler and there's no upside to it. I see what's confusing you but I think you would easily understand how File works if you actually tried compiling some code and observing how it behaves. It seems like you're fixated on theoreticizing without experimentation. I can't explain much better than I already have; I gave you sample code above with comments. File /r "somedir\*.*" packs the contents of somedir when compiling and extracts it to location designated by SetOutPath when running; both is achieved with the same File command.
Your code should look something like this, assuming you have a mix of OSes and there's a GP dir with appropriate subdirs/files in script dir on the compile system:
Your code should look something like this, assuming you have a mix of OSes and there's a GP dir with appropriate subdirs/files in script dir on the compile system:
${If} ${RunningX64}
${DisableX64FSRedirection}
${EndIf}
SetOutPath $SYSDIR\GroupPolicy
# probably a wise thing to do:
CreateDirectory $OUTDIR\BAK
CopyFiles /SILENT $OUTDIR\Adm $OUTDIR\BAK
CopyFiles /SILENT $OUTDIR\Machine $OUTDIR\BAK
CopyFiles /SILENT $OUTDIR\User $OUTDIR\BAK
CopyFiles /SILENT $OUTDIR\gpt.ini $OUTDIR\BAK
${If} ${IsWin8.1}
${If} ${RunningX64}
File /r "GP\8.1 64\*.*"
${Else}
File /r "GP\8.1 32\*.*"
${EndIf}
${ElseIf} ${IsWin8}
${If} ${RunningX64}
File /r "GP\8 64\*.*"
${Else}
File /r "GP\8 32\*.*"
${EndIf}
; etc.
${EndIf} I'm just trying to clarify things, so here goes!Originally Posted by aerDNA View PostYou only need a single script, compiled once. Sure you can use CopyFiles instead of File but there's no reason for it; it doesn't make things simpler and there's no upside to it. I see what's confusing you but I think you would easily understand how File works if you actually tried compiling some code and observing how it behaves. It seems like you're fixated on theoreticizing without experimentation. I can't explain much better than I already have; I gave you sample code above with comments. File /r "somedir\*.*" packs the contents of somedir when compiling and extracts it to location designated by SetOutPath when running; both is achieved with the same File command.
Your code should look something like this, assuming you have a mix of OSes and there's a GP dir with appropriate subdirs/files in script dir on the compile system:
${If} ${RunningX64} ${DisableX64FSRedirection} ${EndIf} SetOutPath $SYSDIR\GroupPolicy # probably a wise thing to do: CreateDirectory $OUTDIR\BAK CopyFiles /SILENT $OUTDIR\Adm $OUTDIR\BAK CopyFiles /SILENT $OUTDIR\Machine $OUTDIR\BAK CopyFiles /SILENT $OUTDIR\User $OUTDIR\BAK CopyFiles /SILENT $OUTDIR\gpt.ini $OUTDIR\BAK ${If} ${IsWin8.1} ${If} ${RunningX64} File /r "GP\8.1 64\*.*" ${Else} File /r "GP\8.1 32\*.*" ${EndIf} ${ElseIf} ${IsWin8} ${If} ${RunningX64} File /r "GP\8 64\*.*" ${Else} File /r "GP\8 32\*.*" ${EndIf} ; etc. ${EndIf}
After I do all the above, (I'm pretending your paths are totally correct and required [are they?]) I can take my compiled script (the installer) to each of my 100 computers and insert it in each CD drive.
Questions: In the script that I compile, my assumption is that I can just do a direct file copy from the locations above to the correct locations of each of the 100 computers. Is nothing else required. Can you give me the code to do that copy etc. or is the code exactly as you've published it above. Are there any changes to the code?
Thank you,
I've been watching this thread a bit, so I'll clarify how File works.
When the script is being compiled, the File command specifies the file you want to include in your installer, so 'File D:\somefile.txt' will include that file in the installer.
When the installer is being executed, the File command turns into the file you want to extract to the directory set by SetOutPath.
So, you set the output directory with SetOutPath, then you use the File command to include/extract a file to that directory (these are the files you include on the CD you have been talking about).
I'm curious now, so question: why are you using CD's for this method? Don't you have a shared folder on the network that every machine has access to? (this is where I would put the installer). I haven't used a CD in years, it's either a flash drive or a shared folder over a network for me. Forgive me if I'm wrong, but it sounds like the technology being used is stuck in the early to mid 2000's.
Like aerDNA said, I hope your sure that this is the process you have to take. I haven't worked in an IT environment yet (I'm still studying for my degree), and even I can see that there's a better way to do it, like Anders said it's better to use network tools provided by Microsoft for managing group policies. For example, the policy for my computer login at the college is controlled by a server, which means it doesn't matter which computer I login to, the policies take effect on whatever computer I choose. Most of the computers are installed with the same image of windows, and every year they rebuild that windows image and reinstall windows on most of those computers.
When the script is being compiled, the File command specifies the file you want to include in your installer, so 'File D:\somefile.txt' will include that file in the installer.
When the installer is being executed, the File command turns into the file you want to extract to the directory set by SetOutPath.
So, you set the output directory with SetOutPath, then you use the File command to include/extract a file to that directory (these are the files you include on the CD you have been talking about).
; set the output directoryThis File command is the main reason for nsis existing in the first place. Without the File command, nsis becomes more of a script executor instead of an installer.
SetOutPath "C:\outputdir"
; include/extract this file to the current output directory
File "C:\source\somefile.txt"
; this results in somefile.txt being installed in C:\outputdir (the full path is C:\outputdir\somefile.txt).
I'm curious now, so question: why are you using CD's for this method? Don't you have a shared folder on the network that every machine has access to? (this is where I would put the installer). I haven't used a CD in years, it's either a flash drive or a shared folder over a network for me. Forgive me if I'm wrong, but it sounds like the technology being used is stuck in the early to mid 2000's.
Like aerDNA said, I hope your sure that this is the process you have to take. I haven't worked in an IT environment yet (I'm still studying for my degree), and even I can see that there's a better way to do it, like Anders said it's better to use network tools provided by Microsoft for managing group policies. For example, the policy for my computer login at the college is controlled by a server, which means it doesn't matter which computer I login to, the policies take effect on whatever computer I choose. Most of the computers are installed with the same image of windows, and every year they rebuild that windows image and reinstall windows on most of those computers.
It should be fairly easy to understand how File works, but with less talk and more scripting. I get the feeling OP doesn't try anything, like he's hoping to figure everything out in advance before writing any code.
As for GP, maybe the machines are not part of a domain, otherwise I guess it would be admin's job to take care of this and they wouldn't ask OP to write a script? The copy method does seem 'dirty' but from what I've seen after some googling, it really seems to be used a lot and I even remember a TechNet page with MS staff instructing people how to do it, without disclaimers or warnings, so I guess it's not considered a bad practice.
As for GP, maybe the machines are not part of a domain, otherwise I guess it would be admin's job to take care of this and they wouldn't ask OP to write a script? The copy method does seem 'dirty' but from what I've seen after some googling, it really seems to be used a lot and I even remember a TechNet page with MS staff instructing people how to do it, without disclaimers or warnings, so I guess it's not considered a bad practice.