Hello,

Working on a PS script that is part of a deployment process for servers...
before I go ahead with searching for the specific registry entries and doing
these configs via direct registry edits, I thought I should check to see if
powershell provides any alternatives?

1) I need to set some settings found via the GUI here:
Tools -> Folder Options -> View tab: things like 'show hidden files and
folders', 'hide extensions for known file types'

2) password policy (local security policy), things like minlength, age,
complexity, etc...

Should I just do direct registry edits or does powershell offer some
alternative? Note: these configs are part of a 'base' config that all
servers get *before* ending up in end-user's hands... and the end users in
this case are all different companies, so there is no common Active
Directory infrastructure for pushing out settings like this via group
policy. Just wanted to mention as I know group policy is the most logical
choice in other scenarios.

actually, this brings another question to mind:



3) in general, for settings that are available and maybe typically set via
group policy, or the local policy really, is there some alternative I should
be aware of besides direct registry edits? powershell or even other? maybe
wmi?

any input would be appreciated, thanks.

even if you haven't AD domain, you should as possible use Local Gropu Policy
(gpedit.msc). With Windows Server 2008 R2/Windows 7 PowerShell have Group
Policy module.

Why registry is not good solution for you - you can't see your settings from
normal GUI console (such gpedit.msc). Also, here is another little benefit
(however this is not secuirty improvement). If someone changes registry -
after system restart these settings will be rewrited with correct settings
from group policy. Of course, you should enable Registry Policy Processing
in gpedit.msc.
--
WBR, Vadims Podans
MVP: PowerShell
PowerShell blog - www.sysadmins.lv

"James" <noone@xxxxxx> rakstija zinojuma
"news:OV4P3f1xJHA.1432@xxxxxx"...

> Hello,
>
> Working on a PS script that is part of a deployment process for servers...
> before I go ahead with searching for the specific registry entries and
> doing these configs via direct registry edits, I thought I should check to
> see if powershell provides any alternatives?
>
> 1) I need to set some settings found via the GUI here:
> Tools -> Folder Options -> View tab: things like 'show hidden files and
> folders', 'hide extensions for known file types'
>
> 2) password policy (local security policy), things like minlength, age,
> complexity, etc...
>
> Should I just do direct registry edits or does powershell offer some
> alternative? Note: these configs are part of a 'base' config that all
> servers get *before* ending up in end-user's hands... and the end users in
> this case are all different companies, so there is no common Active
> Directory infrastructure for pushing out settings like this via group
> policy. Just wanted to mention as I know group policy is the most logical
> choice in other scenarios.
>
> actually, this brings another question to mind:
>
> 3) in general, for settings that are available and maybe typically set via
> group policy, or the local policy really, is there some alternative I
> should be aware of besides direct registry edits? powershell or even
> other? maybe wmi?
>
> any input would be appreciated, thanks.

Hi Vadims, thanks for the reply.

The configs need to be automated, so using gpedit.msc GUI is no good for
this.... good news about R2 and Windows 7 powershell having support, I'm
sure I'll use when I have them. Right now I have to come up with solution
using only Windows Server 2008 and powershell 1.0 (or other command line
tools that can be automated).

Also, I'm not trying to lock these settings down, its just the base config,
or starting point of the machines, before they are actually given to the end
users, who are the real owners of the machines from that point on, so they
can configure any way they want after they have them.

I do however need the settings to also be visible within the GUI tools, I
was not aware they would not be... and suprised. I would think those tools
are pulling the info from the registry anyway?

so far, afaik, my only real options are direct registry edits, or secedit
for the security related settings like password policy.

any further input is welcome.

thanks.


"Vadims Podans [MVP]" <vpodans> wrote in message
news:OM93$J2xJHA.4244@xxxxxx

> even if you haven't AD domain, you should as possible use Local Gropu
> Policy (gpedit.msc). With Windows Server 2008 R2/Windows 7 PowerShell have
> Group Policy module.
>
> Why registry is not good solution for you - you can't see your settings
> from normal GUI console (such gpedit.msc). Also, here is another little
> benefit (however this is not secuirty improvement). If someone changes
> registry - after system restart these settings will be rewrited with
> correct settings from group policy. Of course, you should enable Registry
> Policy Processing in gpedit.msc.
> --
> WBR, Vadims Podans
> MVP: PowerShell
> PowerShell blog - www.sysadmins.lv
>
> "James" <noone@xxxxxx> rakstija zinojuma
> "news:OV4P3f1xJHA.1432@xxxxxx"...

>> Hello,
>>
>> Working on a PS script that is part of a deployment process for
>> servers... before I go ahead with searching for the specific registry
>> entries and doing these configs via direct registry edits, I thought I
>> should check to see if powershell provides any alternatives?
>>
>> 1) I need to set some settings found via the GUI here:
>> Tools -> Folder Options -> View tab: things like 'show hidden files and
>> folders', 'hide extensions for known file types'
>>
>> 2) password policy (local security policy), things like minlength, age,
>> complexity, etc...
>>
>> Should I just do direct registry edits or does powershell offer some
>> alternative? Note: these configs are part of a 'base' config that all
>> servers get *before* ending up in end-user's hands... and the end users
>> in this case are all different companies, so there is no common Active
>> Directory infrastructure for pushing out settings like this via group
>> policy. Just wanted to mention as I know group policy is the most logical
>> choice in other scenarios.
>>
>> actually, this brings another question to mind:
>>
>> 3) in general, for settings that are available and maybe typically set
>> via group policy, or the local policy really, is there some alternative I
>> should be aware of besides direct registry edits? powershell or even
>> other? maybe wmi?
>>
>> any input would be appreciated, thanks.

>

you can create single security template and deploy it via secedit .exe
utility. If you change settings in registry - you'll be unable to see them
in GUI.

>I would think those tools are pulling the info from the registry anyway?

no. GP store settings in security configuration file (or files) and never
read them from registry.

--
WBR, Vadims Podans
MVP: PowerShell
PowerShell blog - www.sysadmins.lv

"James" <noone@xxxxxx> rakstija zinojuma
"news:ujixlb3xJHA.4392@xxxxxx"...

> Hi Vadims, thanks for the reply.
>
> The configs need to be automated, so using gpedit.msc GUI is no good for
> this.... good news about R2 and Windows 7 powershell having support, I'm
> sure I'll use when I have them. Right now I have to come up with solution
> using only Windows Server 2008 and powershell 1.0 (or other command line
> tools that can be automated).
>
> Also, I'm not trying to lock these settings down, its just the base
> config, or starting point of the machines, before they are actually given
> to the end users, who are the real owners of the machines from that point
> on, so they can configure any way they want after they have them.
>
> I do however need the settings to also be visible within the GUI tools, I
> was not aware they would not be... and suprised. I would think those tools
> are pulling the info from the registry anyway?
>
> so far, afaik, my only real options are direct registry edits, or secedit
> for the security related settings like password policy.
>
> any further input is welcome.
>
> thanks.
>
>
> "Vadims Podans [MVP]" <vpodans> wrote in message
> news:OM93$J2xJHA.4244@xxxxxx

>> even if you haven't AD domain, you should as possible use Local Gropu
>> Policy (gpedit.msc). With Windows Server 2008 R2/Windows 7 PowerShell
>> have Group Policy module.
>>
>> Why registry is not good solution for you - you can't see your settings
>> from normal GUI console (such gpedit.msc). Also, here is another little
>> benefit (however this is not secuirty improvement). If someone changes
>> registry - after system restart these settings will be rewrited with
>> correct settings from group policy. Of course, you should enable Registry
>> Policy Processing in gpedit.msc.
>> --
>> WBR, Vadims Podans
>> MVP: PowerShell
>> PowerShell blog - www.sysadmins.lv
>>
>> "James" <noone@xxxxxx> rakstija zinojuma
>> "news:OV4P3f1xJHA.1432@xxxxxx"...

>>> Hello,
>>>
>>> Working on a PS script that is part of a deployment process for
>>> servers... before I go ahead with searching for the specific registry
>>> entries and doing these configs via direct registry edits, I thought I
>>> should check to see if powershell provides any alternatives?
>>>
>>> 1) I need to set some settings found via the GUI here:
>>> Tools -> Folder Options -> View tab: things like 'show hidden files and
>>> folders', 'hide extensions for known file types'
>>>
>>> 2) password policy (local security policy), things like minlength, age,
>>> complexity, etc...
>>>
>>> Should I just do direct registry edits or does powershell offer some
>>> alternative? Note: these configs are part of a 'base' config that all
>>> servers get *before* ending up in end-user's hands... and the end users
>>> in this case are all different companies, so there is no common Active
>>> Directory infrastructure for pushing out settings like this via group
>>> policy. Just wanted to mention as I know group policy is the most
>>> logical choice in other scenarios.
>>>
>>> actually, this brings another question to mind:
>>>
>>> 3) in general, for settings that are available and maybe typically set
>>> via group policy, or the local policy really, is there some alternative
>>> I should be aware of besides direct registry edits? powershell or even
>>> other? maybe wmi?
>>>
>>> any input would be appreciated, thanks.

>>

>

ok. Thanks. I'm always happy to learn more.... so the settings are stored in
files: in the sysvol share on domain controllers for domain based policy I
assume, and somewhere on the local drive for local policy? then, when the
system starts, or user logs on etc, the files are read and that info is used
to set the registry keys? is that correct?

and if I'm correct so far (I'm not sure, I'm hoping you will enlighten me
further), the GUI tools read info directly from the files, rather than the
registry? The operating values would be the ones in the registry though,
right?

thanks again, and any further enlighting would be appreciated.


"Vadims Podans [MVP]" <vpodans> wrote in message
news:%23WjGqt3xJHA.3460@xxxxxx

> you can create single security template and deploy it via secedit .exe
> utility. If you change settings in registry - you'll be unable to see them
> in GUI.
>

>>I would think those tools are pulling the info from the registry anyway?

>
> no. GP store settings in security configuration file (or files) and never
> read them from registry.
>
> --
> WBR, Vadims Podans
> MVP: PowerShell
> PowerShell blog - www.sysadmins.lv
>
> "James" <noone@xxxxxx> rakstija zinojuma
> "news:ujixlb3xJHA.4392@xxxxxx"...

>> Hi Vadims, thanks for the reply.
>>
>> The configs need to be automated, so using gpedit.msc GUI is no good for
>> this.... good news about R2 and Windows 7 powershell having support, I'm
>> sure I'll use when I have them. Right now I have to come up with solution
>> using only Windows Server 2008 and powershell 1.0 (or other command line
>> tools that can be automated).
>>
>> Also, I'm not trying to lock these settings down, its just the base
>> config, or starting point of the machines, before they are actually given
>> to the end users, who are the real owners of the machines from that point
>> on, so they can configure any way they want after they have them.
>>
>> I do however need the settings to also be visible within the GUI tools, I
>> was not aware they would not be... and suprised. I would think those
>> tools are pulling the info from the registry anyway?
>>
>> so far, afaik, my only real options are direct registry edits, or secedit
>> for the security related settings like password policy.
>>
>> any further input is welcome.
>>
>> thanks.
>>
>>
>> "Vadims Podans [MVP]" <vpodans> wrote in message
>> news:OM93$J2xJHA.4244@xxxxxx

>>> even if you haven't AD domain, you should as possible use Local Gropu
>>> Policy (gpedit.msc). With Windows Server 2008 R2/Windows 7 PowerShell
>>> have Group Policy module.
>>>
>>> Why registry is not good solution for you - you can't see your settings
>>> from normal GUI console (such gpedit.msc). Also, here is another little
>>> benefit (however this is not secuirty improvement). If someone changes
>>> registry - after system restart these settings will be rewrited with
>>> correct settings from group policy. Of course, you should enable
>>> Registry Policy Processing in gpedit.msc.
>>> --
>>> WBR, Vadims Podans
>>> MVP: PowerShell
>>> PowerShell blog - www.sysadmins.lv
>>>
>>> "James" <noone@xxxxxx> rakstija zinojuma
>>> "news:OV4P3f1xJHA.1432@xxxxxx"...
>>>> Hello,
>>>>
>>>> Working on a PS script that is part of a deployment process for
>>>> servers... before I go ahead with searching for the specific registry
>>>> entries and doing these configs via direct registry edits, I thought I
>>>> should check to see if powershell provides any alternatives?
>>>>
>>>> 1) I need to set some settings found via the GUI here:
>>>> Tools -> Folder Options -> View tab: things like 'show hidden files and
>>>> folders', 'hide extensions for known file types'
>>>>
>>>> 2) password policy (local security policy), things like minlength, age,
>>>> complexity, etc...
>>>>
>>>> Should I just do direct registry edits or does powershell offer some
>>>> alternative? Note: these configs are part of a 'base' config that all
>>>> servers get *before* ending up in end-user's hands... and the end users
>>>> in this case are all different companies, so there is no common Active
>>>> Directory infrastructure for pushing out settings like this via group
>>>> policy. Just wanted to mention as I know group policy is the most
>>>> logical choice in other scenarios.
>>>>
>>>> actually, this brings another question to mind:
>>>>
>>>> 3) in general, for settings that are available and maybe typically set
>>>> via group policy, or the local policy really, is there some alternative
>>>> I should be aware of besides direct registry edits? powershell or even
>>>> other? maybe wmi?
>>>>
>>>> any input would be appreciated, thanks.
>>>

>>

> so the settings are stored in files: in the sysvol share on domain

> controllers for domain based policy I assume, and somewhere on the local
> drive for local policy?

exactly. Local templates are stored here:
C:\WINDOWS\security\templates (in Windows XP/Windows Server 2003)

> then, when the system starts, or user logs on etc, the files are read and
> that info is used to set the registry keys? is that correct?

no. It depends on group policy processing mode. When you apply group policy
settings, they change registry only once. Even if after this you manually
change appropriate registry keys. Therefore you can get setting
inconsistence between GP and registry. For this purposes GP have GP
processing modes settings:
Computer Configuration -> Administrative Templates -> System -> group
Policy.
here we have some settings, such Registry policy processing and Security
policy processing mode. If you configure these options, after each systems
restart (in workgroups) registry keys will be overwrited from GP settings.

> the GUI tools read info directly from the files, rather than the registry?

yes.
--
WBR, Vadims Podans
MVP: PowerShell
PowerShell blog - www.sysadmins.lv

"James" <noone@xxxxxx> rakstija zinojuma
"news:#ebFQP4xJHA.5496@xxxxxx"...

> ok. Thanks. I'm always happy to learn more.... so the settings are stored
> in files: in the sysvol share on domain controllers for domain based
> policy I assume, and somewhere on the local drive for local policy? then,
> when the system starts, or user logs on etc, the files are read and that
> info is used to set the registry keys? is that correct?
>
> and if I'm correct so far (I'm not sure, I'm hoping you will enlighten me
> further), the GUI tools read info directly from the files, rather than the
> registry? The operating values would be the ones in the registry though,
> right?
>
> thanks again, and any further enlighting would be appreciated.
>
>
> "Vadims Podans [MVP]" <vpodans> wrote in message
> news:%23WjGqt3xJHA.3460@xxxxxx

>> you can create single security template and deploy it via secedit .exe
>> utility. If you change settings in registry - you'll be unable to see
>> them in GUI.
>>

>>>I would think those tools are pulling the info from the registry anyway?

>>
>> no. GP store settings in security configuration file (or files) and never
>> read them from registry.
>>
>> --
>> WBR, Vadims Podans
>> MVP: PowerShell
>> PowerShell blog - www.sysadmins.lv
>>
>> "James" <noone@xxxxxx> rakstija zinojuma
>> "news:ujixlb3xJHA.4392@xxxxxx"...

>>> Hi Vadims, thanks for the reply.
>>>
>>> The configs need to be automated, so using gpedit.msc GUI is no good for
>>> this.... good news about R2 and Windows 7 powershell having support, I'm
>>> sure I'll use when I have them. Right now I have to come up with
>>> solution using only Windows Server 2008 and powershell 1.0 (or other
>>> command line tools that can be automated).
>>>
>>> Also, I'm not trying to lock these settings down, its just the base
>>> config, or starting point of the machines, before they are actually
>>> given to the end users, who are the real owners of the machines from
>>> that point on, so they can configure any way they want after they have
>>> them.
>>>
>>> I do however need the settings to also be visible within the GUI tools,
>>> I was not aware they would not be... and suprised. I would think those
>>> tools are pulling the info from the registry anyway?
>>>
>>> so far, afaik, my only real options are direct registry edits, or
>>> secedit for the security related settings like password policy.
>>>
>>> any further input is welcome.
>>>
>>> thanks.
>>>
>>>
>>> "Vadims Podans [MVP]" <vpodans> wrote in message
>>> news:OM93$J2xJHA.4244@xxxxxx
>>>> even if you haven't AD domain, you should as possible use Local Gropu
>>>> Policy (gpedit.msc). With Windows Server 2008 R2/Windows 7 PowerShell
>>>> have Group Policy module.
>>>>
>>>> Why registry is not good solution for you - you can't see your settings
>>>> from normal GUI console (such gpedit.msc). Also, here is another little
>>>> benefit (however this is not secuirty improvement). If someone changes
>>>> registry - after system restart these settings will be rewrited with
>>>> correct settings from group policy. Of course, you should enable
>>>> Registry Policy Processing in gpedit.msc.
>>>> --
>>>> WBR, Vadims Podans
>>>> MVP: PowerShell
>>>> PowerShell blog - www.sysadmins.lv
>>>>
>>>> "James" <noone@xxxxxx> rakstija zinojuma
>>>> "news:OV4P3f1xJHA.1432@xxxxxx"...
>>>>> Hello,
>>>>>
>>>>> Working on a PS script that is part of a deployment process for
>>>>> servers... before I go ahead with searching for the specific registry
>>>>> entries and doing these configs via direct registry edits, I thought I
>>>>> should check to see if powershell provides any alternatives?
>>>>>
>>>>> 1) I need to set some settings found via the GUI here:
>>>>> Tools -> Folder Options -> View tab: things like 'show hidden files
>>>>> and folders', 'hide extensions for known file types'
>>>>>
>>>>> 2) password policy (local security policy), things like minlength,
>>>>> age, complexity, etc...
>>>>>
>>>>> Should I just do direct registry edits or does powershell offer some
>>>>> alternative? Note: these configs are part of a 'base' config that all
>>>>> servers get *before* ending up in end-user's hands... and the end
>>>>> users in this case are all different companies, so there is no common
>>>>> Active Directory infrastructure for pushing out settings like this via
>>>>> group policy. Just wanted to mention as I know group policy is the
>>>>> most logical choice in other scenarios.
>>>>>
>>>>> actually, this brings another question to mind:
>>>>>
>>>>> 3) in general, for settings that are available and maybe typically set
>>>>> via group policy, or the local policy really, is there some
>>>>> alternative I should be aware of besides direct registry edits?
>>>>> powershell or even other? maybe wmi?
>>>>>
>>>>> any input would be appreciated, thanks.
>>>>
>>>

>

thank you for this info, it is very helpful. I appreciate it.

"Vadims Podans [MVP]" <vpodans> wrote in message
news:uIPlJd8xJHA.1372@xxxxxx

>> so the settings are stored in files: in the sysvol share on domain
>> controllers for domain based policy I assume, and somewhere on the local
>> drive for local policy?

> exactly. Local templates are stored here:
> C:\WINDOWS\security\templates (in Windows XP/Windows Server 2003)
>

>> then, when the system starts, or user logs on etc, the files are read and
>> that info is used to set the registry keys? is that correct?

>
> no. It depends on group policy processing mode. When you apply group
> policy settings, they change registry only once. Even if after this you
> manually change appropriate registry keys. Therefore you can get setting
> inconsistence between GP and registry. For this purposes GP have GP
> processing modes settings:
> Computer Configuration -> Administrative Templates -> System -> group
> Policy.
> here we have some settings, such Registry policy processing and Security
> policy processing mode. If you configure these options, after each systems
> restart (in workgroups) registry keys will be overwrited from GP settings.
>

>> the GUI tools read info directly from the files, rather than the
>> registry?

> yes.
> --
> WBR, Vadims Podans
> MVP: PowerShell
> PowerShell blog - www.sysadmins.lv
>
> "James" <noone@xxxxxx> rakstija zinojuma
> "news:#ebFQP4xJHA.5496@xxxxxx"...

>> ok. Thanks. I'm always happy to learn more.... so the settings are stored
>> in files: in the sysvol share on domain controllers for domain based
>> policy I assume, and somewhere on the local drive for local policy? then,
>> when the system starts, or user logs on etc, the files are read and that
>> info is used to set the registry keys? is that correct?
>>
>> and if I'm correct so far (I'm not sure, I'm hoping you will enlighten me
>> further), the GUI tools read info directly from the files, rather than
>> the registry? The operating values would be the ones in the registry
>> though, right?
>>
>> thanks again, and any further enlighting would be appreciated.
>>
>>
>> "Vadims Podans [MVP]" <vpodans> wrote in message
>> news:%23WjGqt3xJHA.3460@xxxxxx

>>> you can create single security template and deploy it via secedit .exe
>>> utility. If you change settings in registry - you'll be unable to see
>>> them in GUI.
>>>
>>>>I would think those tools are pulling the info from the registry anyway?
>>>
>>> no. GP store settings in security configuration file (or files) and
>>> never read them from registry.
>>>
>>> --
>>> WBR, Vadims Podans
>>> MVP: PowerShell
>>> PowerShell blog - www.sysadmins.lv
>>>
>>> "James" <noone@xxxxxx> rakstija zinojuma
>>> "news:ujixlb3xJHA.4392@xxxxxx"...
>>>> Hi Vadims, thanks for the reply.
>>>>
>>>> The configs need to be automated, so using gpedit.msc GUI is no good
>>>> for this.... good news about R2 and Windows 7 powershell having
>>>> support, I'm sure I'll use when I have them. Right now I have to come
>>>> up with solution using only Windows Server 2008 and powershell 1.0 (or
>>>> other command line tools that can be automated).
>>>>
>>>> Also, I'm not trying to lock these settings down, its just the base
>>>> config, or starting point of the machines, before they are actually
>>>> given to the end users, who are the real owners of the machines from
>>>> that point on, so they can configure any way they want after they have
>>>> them.
>>>>
>>>> I do however need the settings to also be visible within the GUI tools,
>>>> I was not aware they would not be... and suprised. I would think those
>>>> tools are pulling the info from the registry anyway?
>>>>
>>>> so far, afaik, my only real options are direct registry edits, or
>>>> secedit for the security related settings like password policy.
>>>>
>>>> any further input is welcome.
>>>>
>>>> thanks.
>>>>
>>>>
>>>> "Vadims Podans [MVP]" <vpodans> wrote in message
>>>> news:OM93$J2xJHA.4244@xxxxxx
>>>>> even if you haven't AD domain, you should as possible use Local Gropu
>>>>> Policy (gpedit.msc). With Windows Server 2008 R2/Windows 7 PowerShell
>>>>> have Group Policy module.
>>>>>
>>>>> Why registry is not good solution for you - you can't see your
>>>>> settings from normal GUI console (such gpedit.msc). Also, here is
>>>>> another little benefit (however this is not secuirty improvement). If
>>>>> someone changes registry - after system restart these settings will be
>>>>> rewrited with correct settings from group policy. Of course, you
>>>>> should enable Registry Policy Processing in gpedit.msc.
>>>>> --
>>>>> WBR, Vadims Podans
>>>>> MVP: PowerShell
>>>>> PowerShell blog - www.sysadmins.lv
>>>>>
>>>>> "James" <noone@xxxxxx> rakstija zinojuma
>>>>> "news:OV4P3f1xJHA.1432@xxxxxx"...
>>>>>> Hello,
>>>>>>
>>>>>> Working on a PS script that is part of a deployment process for
>>>>>> servers... before I go ahead with searching for the specific registry
>>>>>> entries and doing these configs via direct registry edits, I thought
>>>>>> I should check to see if powershell provides any alternatives?
>>>>>>
>>>>>> 1) I need to set some settings found via the GUI here:
>>>>>> Tools -> Folder Options -> View tab: things like 'show hidden files
>>>>>> and folders', 'hide extensions for known file types'
>>>>>>
>>>>>> 2) password policy (local security policy), things like minlength,
>>>>>> age, complexity, etc...
>>>>>>
>>>>>> Should I just do direct registry edits or does powershell offer some
>>>>>> alternative? Note: these configs are part of a 'base' config that all
>>>>>> servers get *before* ending up in end-user's hands... and the end
>>>>>> users in this case are all different companies, so there is no common
>>>>>> Active Directory infrastructure for pushing out settings like this
>>>>>> via group policy. Just wanted to mention as I know group policy is
>>>>>> the most logical choice in other scenarios.
>>>>>>
>>>>>> actually, this brings another question to mind:
>>>>>>
>>>>>> 3) in general, for settings that are available and maybe typically
>>>>>> set via group policy, or the local policy really, is there some
>>>>>> alternative I should be aware of besides direct registry edits?
>>>>>> powershell or even other? maybe wmi?
>>>>>>
>>>>>> any input would be appreciated, thanks.
>>>>>
>>>>

>>