Make PowerShell able to enable logging of script block execution on Unix platforms #5791

daxian-dbw · 2018-01-04T20:29:09Z

PR Summary

Enable ScriptBlockLogging on Linux/macOS by moving the GroupPolicy configurations to the configuration file PowerShellProperties.json. Including the following tasks:

Enable the logging via MshLog.cs on Unix platforms. (the 1st commit)
Refactor PropertyAccessor.cs. (the 2nd commit)
- Remove the unneeded base type
- Rename 'ConfigPropertyAccessor' to PowerShellConfig
- Move PowerShellConfig to the namespace System.Management.Automation.Configuration
Rename the enum PropertyScope to ConfigScope. (the 3rd commit)
Rename file PropertyAccessor.cs to PSConfiguration.cs. (the 4th commit)
Refactor GroupPolicy setting related code to use the configuration file. (the 5th commit)
- Followings are the policy settings that are moved to the configuration file.
  - ScriptExecution settings (used in SecuritySupport.cs)
  - ScriptBlockLogging settings (used in CompiledScriptBlock.cs)
  - ModuleLogging settings (used in ModuleCmdletBase.cs)
  - ProtectedEventLogging settings (used in CompiledScriptBlock.cs)
  - Transcription settings (used in MshHostUserInterface.cs)
  - UpdatableHelp setting (used in UpdatableHelpSystem.cs)
  - ConsoleSessionConfiguration settings (used in CommandLineParameterParser.cs)
- In PSConfiguration.cs, updated ReadValueFromFile<T> to make it flexible to allow a custom JsonObject parsing implementation delegate passed in.
- In PSConfiguration.cs, added GetPowerShellPolicies(ConfigScope scope) and make DefaultSourcePath setting part of the new policy settings because it is part of the group policy on windows powershell.
- In Utils.cs, replace the method GetGroupPolicySetting with T GetPolicySetting<T>(ConfigScope[] preferenceOrder) where T : PolicyBase. The old method was for reading from Registry, while the new one is for reading from configuration file.
- Changes in other files are the corresponding changes due to GetGroupPolicySetting being replaced.
Add xUnit tests to test reading policy settings from the configuration files in different scenarios. (the 6th commit)
- The xUnit tests are running in parallel by default. Tests for reading policy settings manipulate the configuration file and thus are in conflict with other xUnit tests. So the existing xUnit tests are moved to the namespace PSTests.Parallel and the new tests are moved to PSTests.Sequential and the corresponding build scripts are updated to run sequential xUnit tests first and then run other xUnit tests in parallel.
A minor change to fix an issue in xUnit test and another minor change to SysLogProvider to make ScriptBlock logging not ignored on Unix platforms. (the 7th commit)
Re-enable GPO support on Windows. On Windows, we first query GPO from registry, if the required policy is not defined, then we query policies from the configuration file. (the 9th commit)
Rename PowerShellProperties.json to powershell.config.json. (the 10th commit)

An example of the configuration file `powershell.config.json`

{
  "Microsoft.PowerShell:ExecutionPolicy": "RemoteSigned",
  "PowerShellPolicies": {
    "ScriptExecution": {
      "ExecutionPolicy": "RemoteSigned",
      "EnableScripts": true
    },
    "ScriptBlockLogging": {
      "EnableScriptBlockInvocationLogging": true,
      "EnableScriptBlockLogging": true
    },
    "ModuleLogging": {
      "EnableModuleLogging": false,
      "ModuleNames": [
        "PSReadline",
        "PowerShellGet"
      ]
    },
    "ProtectedEventLogging": {
      "EnableProtectedEventLogging": false,
      "EncryptionCertificate": [
        "Joe"
      ]
    },
    "Transcription": {
      "EnableTranscripting": true,
      "EnableInvocationHeader": true,
      "OutputDirectory": "F:\\tmp\\new"
    },
    "UpdatableHelp": {
      "DefaultSourcePath": "f:\\temp"
    },
    "ConsoleSessionConfiguration": {
      "EnableConsoleSessionConfiguration": false,
      "ConsoleSessionConfigurationName": "name"
    }
  },
  "LogLevel": "verbose"
}

Limitation that needs to be documented

On Unix platform, the default logging level filter is information, while the logging of script block execution writes out verbose level logging. So the configuration entry "LogLevel": "verbose" is needed along with the settings in "ScriptBlockLogging". This needs to be documented.

Documentation needed

We need documentation to clarify how logging works in PowerShell. Not sure if we already have some docs about it. Issue MicrosoftDocs/PowerShell-Docs#2017 is opened.

PR Checklist

Note: Please mark anything not applicable to this PR NA.

PR has a meaningful title
- Use the present tense and imperative mood when describing your changes
Summarized changes
User facing Documentation needed
- Issue filed - Issue link:
Change is not breaking
Make sure you've added a new test if existing tests do not effectively test the code changed
- Add [feature] if the change is significant or affectes feature tests
This PR is ready to merge and is not Work in Progress.
- If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

daxian-dbw · 2018-01-04T20:36:03Z

There are a lot of changes in this PR. When reviewing this PR, I recommend you review each commit because I intentionally group logically related changes into separate commits.

- Remove the unneeded base type; - Rename 'ConfigPropertyAccessor' to 'PowerShellConfig'; - Move 'PowerShellConfig' to the namespace 'System.Management.Automation.Configuration'

SteveL-MSFT · 2018-01-04T21:46:59Z

src/Microsoft.PowerShell.ConsoleHost/host/msh/CommandLineParameterParser.cs

        private static string GetConfigurationNameFromGroupPolicy()
        {
            // Current user policy takes precedence.
-            var groupPolicySettings = Utils.GetGroupPolicySetting(s_groupPolicyBase, s_consoleSessionConfigurationKey, Utils.RegCurrentUserThenLocalMachine);
-            if (groupPolicySettings != null)
+            var consoleSessionSetting = Utils.GetPolicySetting<ConsoleSessionConfiguration>(Utils.CurrentUserThenSystemWideConfig);


With this change, the Windows PowerShell GPO settings don't apply to PSCore6, correct? This seems correct to me, but is a breaking change. We should label this PR as such. cc @joeyaiello

Yes, GPO settings in Registry won't apply to PowerShell Core. I have added the breaking change label. Thanks for catching that.

This does not seem correct to me. @Indhukrishna DSC has had feedback that seems to indicate that they expect GPO to apply.

I will start to work on enabling GPO as well on windows. The preference order of the settings should be config file --> GPO, meaning if a policy setting is defined in the config file, then use it; if it's not defined in the config file, query registry. This way, you can have control whether you want the GPO settings to take effect.

Common rule is that Computer GPO is high priority, then User GPO, then computer wide config, then user config. It is critical rule and security related.

Update.
Software\Policies\Microsoft\Windows\PowerShell - here Policies assume that it is high priority and should overlap other configs - users can not change its.
Software\Microsoft\Windows\PowerShell - it is a normal config corresponding to a text config file. This setting can be set manually by user or by using Group Policy Preferences (GPP). I think it should be low priority over a text config file (looks as changing defaults or set recommended defaults that the user can change by a config file).

For the policy related settings, we are having a debate on which one should take preference. I will talk to @TravisEz13 later today about it.
For non-policy related settings, we shouldn't use registry settings anymore but only refer to the config file.

The conclusion is: on windows, we query group policies from registry first, and if the requested policy is not defined in GP, then we query from the configuration file.
New commit has been pushed to enable this.

For non-policy related settings, we shouldn't use registry settings anymore but only refer to the config file.

I don't agree - GPO is great Enterprise feature and Domain Admins should have full and flexible control on PowerShell. We could discuss this in a Issue (as I mention below too).

I mean "non-policy related settings", like the settings in "SOFTWARE\Microsoft\PowerShell" today. They are not group policies.

SteveL-MSFT

Still reviewing

SteveL-MSFT · 2018-01-04T21:54:23Z

src/System.Management.Automation/engine/PSConfiguration.cs

-        /// {
-        ///     "DefaultSourcePath" : "path to local updatable help location"
-        /// }
+        /// Corresponding settings of the original Group Policies


If we're moving GPO support, we shouldn't mention "original Group Policies", just call it "PowerShell Policies"

Since we now re-enabled the GPO support on Windows, I will leave this comment unchanged.

SteveL-MSFT · 2018-01-04T21:59:05Z

src/System.Management.Automation/engine/hostifaces/LocalPipeline.cs

@@ -269,7 +269,7 @@ internal static int ReadRegistryInt(string policyValueName, int defaultValue)
            RegistryKey key;
            try
            {
-                key = Registry.LocalMachine.OpenSubKey(Utils.GetRegistryConfigurationPrefix());
+                key = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\PowerShell\\1\\ShellIds");


this path should be a const somewhere

This code is in a #if !CORECLR ... #endif block. I leave the registry key path here only for reference, so that when we clean up this !CORECLR block, we know what the key is.

dantraMSFT · 2018-01-04T23:07:23Z

src/System.Management.Automation/engine/runtime/CompiledScriptBlock.cs

            {
                if (!scriptBlock.HasLogged || InternalTestHooks.ForceScriptBlockLogging)
                {
                    // If script block logging is explicitly disabled, or it's from a trusted
                    // file or internal, skip logging.
-                    if (ScriptBlockLoggingExplicitlyDisabled() ||
+                    if (logSetting?.EnableScriptBlockLogging == false ||
                        scriptBlock.ScriptBlockData.IsProductCode)


Why isn't the IsProductCode check in the outer if statement since it's never logged when set.

Theoretically, this can be re-written as

if ((force && logSetting?.EnableScriptBlockLogging != false) || logSetting?.EnableScriptBlockLogging == true) { if ((!scriptBlock.HasLogged || InternalTestHooks.ForceScriptBlockLogging) && !scriptBlock.ScriptBlockData.IsProductCode) { .... } }

Or even more aggressively, these two if blocks can be merged into one. But this doesn't look very readable, so I think I'm fine with the original code.

dantraMSFT · 2018-01-04T23:16:41Z

src/System.Management.Automation/engine/runtime/CompiledScriptBlock.cs

            {
                if (!scriptBlock.HasLogged || InternalTestHooks.ForceScriptBlockLogging)
                {
                    // If script block logging is explicitly disabled, or it's from a trusted
                    // file or internal, skip logging.
-                    if (ScriptBlockLoggingExplicitlyDisabled() ||
+                    if (logSetting?.EnableScriptBlockLogging == false ||


This behavior change may be confusing without some documentation.
We've essentially now have 3 logging states, on, off, and warnings. When the setting is not defined, scripts that have suspicious content are logged.

I suggest a doc change to clarify this.

There is no behavior change, the check logSetting?.EnableScriptBlockLogging == false is to make sure that the EnableScriptBlockLogging is explicitly set to false in the config file. If you look at the original implementation of ScriptBlockLoggingExplicitlyDisabled(), it returns true only if the registry key EnableScriptBlockLogging exists and its value is explicitly 0.

I agree to have docs to clarify how logging works in PowerShell. Not sure if we already have some docs about it.

@daxian-dbw Could you please add this in PR description for future docs?

Yes, a documentation section is added to PR description.

dantraMSFT · 2018-01-04T23:47:57Z

src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs

            {
-                object enableModuleLoggingValue = null;
-                if (groupPolicySettings.TryGetValue("EnableModuleLogging", out enableModuleLoggingValue))
+                if (moduleLogging.EnableModuleLogging == false)


Do we really need multiple return paths? Why not if (... == false) else if (... == true) and set status in both cases.

I didn't change the original code, will update it to set status in both cases.

dantraMSFT · 2018-01-04T23:54:39Z

src/System.Management.Automation/engine/hostifaces/MshHostUserInterface.cs

@@ -921,7 +921,7 @@ internal static TranscriptionOption GetSystemTranscriptOption(TranscriptionOptio
                {
                    if (systemTranscript == null)


This lock is not used consistently with other usages. if the intent is to return the updated or original value, the lock should also encapsulate both the "if (transcription != null)" block and the implied else block.

As written, there is a possible race between this path and StopAllTranscribing

I didn't change the original code. I guess you are right, this method could return a TranscriptionOption object or null depending on whether StopAllTranscribing set systemTranscript to null before return systemTranscript; in this method. But I'm not familiar enough with the transcribing code to know if that could be a problem.

Can you open an issue tracking this comment? We can look at the transcribing code more closely when addressing that issue.

SteveL-MSFT · 2018-01-05T04:21:26Z

src/System.Management.Automation/engine/PSConfiguration.cs

+    internal sealed class ScriptExecution : PolicyBase
+    {
+        public string ExecutionPolicy { get; set; }
+        public bool? EnableScripts { get; set; }


Not sure I understand the value of having this nullable. EnableScripts == null is same as EnableScripts == true, correct? Same question for the nullable properties below where they should have a default value and being null is the same as the default value.

EnableScripts == null means this setting is not defined in the config file, so it's up to powershell to define the default behavior. EnableScripts == true means it's defined in the config file and the value is true. Likewise, EnableScripts == false means it's defined in the config file and the value is false.

It's the same in registry -- a key is not defined, which means the application needs to use the pre-defined behavior; when the key is defined, the value will be either 1 or 0.

An example is the use of EnableScriptBlockLogging in LogScriptBlockCreation(ScriptBlock scriptBlock, bool force)

when it's explicitly set to 'true' (1 in registry), we always do script block logging;

when it's not defined, we do script block logging when force == true

when it's explicitly set to 'false' (0 in registry), we always disable script block logging, even if force == true.

Ok, the force case makes sense that there is a difference with null. Thanks.

I don't like the nullable too. I see no reason to emulate registry keys. If now we use static classes it is more readable and maintainable to set defaults explicitly. Force works with this too.

I don't think it's mimicking registry keys, but a requirement to represent three states: enabled, disabled and undefined. Without bool?, if EnableScriptBlockLogging is not specified in the config file while EnableScriptBlockInvocationLogging is specified, then the deserialized ScriptBlockLogging object will have EnableScriptBlockLogging set to false (the default value), which will be interpreted as "script block logging" is explicitly disabled.

The EnableScriptBlockLogging example is from existing code, I didn't change the logic. If it turns out we don't need the bool? type in future, we can always change it since it's internal.

iSazonov · 2018-01-05T15:56:34Z

src/System.Management.Automation/engine/PropertyAccessor.cs

            // Sets the per-user configuration directory
            // Note: This directory may or may not exist depending upon the
            // execution scenario. Writes will attempt to create the directory
            // if it does not already exist.
-            //
            appDataConfigDirectory = Utils.GetUserConfigurationDirectory();


We can install PowerShell Core side-by-side with other PowerShell Core-s. So we should have configs for "default" system wide installation and for "local" for every user installation.
Also it seems we should have GPO option - "Force GPO for Side-By-Side PowerShell installations" - by default we should apply GPO only for system wide PowerShell installation.

Based on internal discussion today, the current plan is to have PSCore6 GPO settings separate from Windows PowerShell. For now, we don't plan to have side-by-side GPO settings per version of PSCore6 until there is customer need for it. New admx will be published later for the PSCore6 settings (which will be the same as Windows PowerShell, but reside in a different location in registry).

GPO is Enterprise feature. GPO should allow Domain Admins get full control on PowerShell. I full trust MSFT experts but I'd prefer discuss GPO in a Issue. Also we forget about AppLocker.
I'd as Domain Admin prefer don't separate PowerShell Core GPO - it is better by default use Windows PowerShell setting until PowerShell Core GPOs is set explicitly otherwise users can ignore corporate policies.

@iSazonov since PSCore6 is not inbox in Windows and doesn't replace Windows PowerShell, we shouldn't use the same settings. PSCore6 in this case is no different from any 3rd party app.

PaulHigin · 2018-01-05T16:34:35Z

src/System.Management.Automation/engine/PSConfiguration.cs

+                    var settings = new JsonSerializerSettings() { TypeNameHandling = TypeNameHandling.None, MaxDepth = 10 };
+                    var serializer = JsonSerializer.Create(settings);
+
+                    var configData = serializer.Deserialize<JObject>(jsonReader);


Has a security review been done on this code? Is it possible for the deserializer to create arbitrary types or run arbitrary code? If so is it possible to apply a schema to mitigate? This could be a possible security hole when we (re) implement PowerShell white listing protection. Can you add a comment about this possible vulnerability and create an issue to track?

is it possible to apply a schema to mitigate

We have a PR for Test-Json - it can help here.

@PaulHigin the use of JsonSerailizer here is the same as in ConverFrom/ConverTo-Json cmdlets. I will add a comment and create an issue.

I had a closer look at the usage, and think it should be safe. The usage here can only convert values to the limited types: string, bool, string[], bool?, and sub types of PolicyBase.

@daxian-dbw If that is the case then we should be Ok. Thanks.

Do PowerShell silently eat wrong config options without the schema check? It is bad UX.

PowerShell currently doesn't do schema check on the config file, which needs to be addressed. I opened #5809 with 3 tasks. Feel free to bring up more to discuss.

iSazonov · 2018-01-05T17:18:59Z

test/csharp/test_PSConfiguration.cs

+                // Create the CurrentUser config directory if it doesn't exist
+                Directory.CreateDirectory(currentUserConfigDirectory);
+            }
+
            systemWideConfigFile = Path.Combine(systemWideConfigDirectory, "PowerShellProperties.json");
            currentUserConfigFile = Path.Combine(currentUserConfigDirectory, "PowerShellProperties.json");


I believe Properties should be replaced with Config.
PowerShellConfig.json or PowerShell.Config.json or PowerShell.config.json

I don't like this file name either. I will see if I can rename it.

Pushed new commit to rename the file. The file name is now powershell.config.json.

iSazonov · 2018-01-05T17:33:58Z

src/System.Management.Automation/engine/PropertyAccessor.cs

-        /// Lock used to enable multiple concurrent readers and singular write locks within a
-        /// single process.
-        /// TODO: This solution only works for IO from a single process. A more robust solution is needed to enable ReaderWriterLockSlim behavior between processes.
+        /// Lock used to enable multiple concurrent readers and singular write locks within a single process.


We have lock (s_cachedPolicies) in Utils.cs - maybe that's enough?

There are other settings except for the policy related ones and they may query the config file simultaneously, so this lock is needed.

I think we could find a way to use only one global lock - if we want to have consistency, it doesn't matter how and what settings change.

The querying for GP setting is a hot code path, especially for the script block logging, every script block execution will query for it. The lock s_cachedPolicies is to make sure that when multiple threads are querying for GP settings at the same time, only one thread will actually hit and read the configuration file.

On windows, group policy settings from registry takes precedence over the configuration file. If a policy is not defined in GP, then we query from configuration file.

dantraMSFT · 2018-01-05T18:22:42Z

src/System.Management.Automation/engine/hostifaces/MshHostUserInterface.cs

@@ -921,7 +921,7 @@ internal static TranscriptionOption GetSystemTranscriptOption(TranscriptionOptio
                {
                    if (systemTranscript == null)


dantraMSFT · 2018-01-06T00:07:52Z

src/System.Management.Automation/engine/Utils.cs

+        /// <summary>
+        /// Get a specific kind of policy setting from the configuration file.
+        /// </summary>
+        internal static T GetPolicySettingFromConfigFile<T>(ConfigScope[] preferenceOrder) where T : PolicyBase, new()


Shouldn't this be private?

Yes, it should. Will update.

dantraMSFT · 2018-01-06T00:09:25Z

src/System.Management.Automation/engine/Utils.cs

+        /// <summary>
+        /// Get a specific kind of policy setting from the group policy registry key.
+        /// </summary>
+        internal static T GetPolicySettingFromGPO<T>(ConfigScope[] preferenceOrder) where T : PolicyBase, new()


This should be private, right?

Yes, it should. Will update.

dantraMSFT · 2018-01-06T00:14:09Z

src/System.Management.Automation/engine/PSConfiguration.cs

@@ -29,7 +29,7 @@ internal sealed class PowerShellConfig

        private string psHomeConfigDirectory;
        private string appDataConfigDirectory;
-        private const string configFileName = "PowerShellProperties.json";
+        private const string configFileName = "powershell.config.json";


about_Logging.md will need to be updated.
See https://github.com/PowerShell/PowerShell-Docs/blob/staging/reference/6/Microsoft.PowerShell.Core/About/about_Logging.md

Opened MicrosoftDocs/PowerShell-Docs#2017 to track the documentation update.

Note that about_logging.md needs to be updated regardless since it refers to 'PowerShellProperties.json'.

TravisEz13 · 2018-01-06T00:40:09Z

src/System.Management.Automation/engine/Utils.cs

+            {nameof(UpdatableHelp), @"Software\Policies\Microsoft\PowerShellCore\UpdatableHelp"},
+            {nameof(ConsoleSessionConfiguration), @"Software\Policies\Microsoft\PowerShellCore\ConsoleSessionConfiguration"}
+        };
+        private readonly static ConcurrentDictionary<Tuple<ConfigScope, string>, PolicyBase> s_cachedPoliciesFromRegistry =


Really, we should register for GP change notifications and clear the cache. Not a regression, so, can you add a comment or file an issue: https://msdn.microsoft.com/en-us/library/windows/desktop/aa374404(v=vs.85).aspx

Issue #5804 is opened to track this.

Concern has been addressed.

…e set

daxian-dbw · 2018-01-08T00:51:50Z

@dantraMSFT @SteveL-MSFT @iSazonov @TravisEz13 I think all comments have been addressed (code updated, or question answered, or issue opened). Can you please take another look to see if the PR is ready to merge?

SteveL-MSFT · 2018-01-08T17:22:18Z

src/System.Management.Automation/engine/PSConfiguration.cs

+
+    /// <summary>
+    /// The GroupPolicy related settings used in PowerShell are as follows in Registry:
+    ///  - Software\Policies\Microsoft\Windows\PowerShell -- { EnableScripts (0 or 1); ExecutionPolicy (string) }


Needs to be updated as we're putting it under ...\Microsoft\PowerShellCore now

Will do. Done.

SteveL-MSFT · 2018-01-08T17:25:13Z

src/System.Management.Automation/engine/Utils.cs

+                        case nameof(Transcription):               result = policies.Transcription; break;
+                        case nameof(UpdatableHelp):               result = policies.UpdatableHelp; break;
+                        case nameof(ConsoleSessionConfiguration): result = policies.ConsoleSessionConfiguration; break;
+                        default: Diagnostics.Assert(false, "Unreachable code"); break;


Perhaps have the same assert message as line 656 below?

TravisEz13

We should add GPO tests at some point.

daxian-dbw · 2018-01-08T19:52:26Z

Thanks all for the reviews!

SteveL-MSFT · 2018-01-08T22:09:53Z

@TravisEz13 can you open an issue to track the GPO tests?

…werShell Core (PowerShell#5791) Make PowerShell Core reads group policy settings from different registry keys (Windows only) and the configuration files (both Windows and Unix). - On Windows, move to different GPO registry keys. - On both Windows and Unix, read GPO related settings from the configuration file `powershell.config.json`. - On Windows, the policy settings in registry take precedence over the configuration file. - Enable policy controlled logging and transcription on Unix.

…werShell Core (#5791) Make PowerShell Core reads group policy settings from different registry keys (Windows only) and the configuration files (both Windows and Unix). - On Windows, move to different GPO registry keys. - On both Windows and Unix, read GPO related settings from the configuration file `powershell.config.json`. - On Windows, the policy settings in registry take precedence over the configuration file. - Enable policy controlled logging and transcription on Unix.

daxian-dbw self-assigned this Jan 4, 2018

daxian-dbw requested review from TravisEz13, SteveL-MSFT, dantraMSFT, adityapatwardhan and PaulHigin January 4, 2018 20:29

daxian-dbw requested review from anmenaga, BrucePay, Francisco-Gamino and lzybkr as code owners January 4, 2018 20:29

daxian-dbw removed request for BrucePay and Francisco-Gamino January 4, 2018 20:29

lzybkr removed their request for review January 4, 2018 21:03

daxian-dbw added 7 commits January 4, 2018 13:40

Enable logging on Linux through MshLog

39af334

Refactor 'PropertyAccessor.cs'

3dd86f5

- Remove the unneeded base type; - Rename 'ConfigPropertyAccessor' to 'PowerShellConfig'; - Move 'PowerShellConfig' to the namespace 'System.Management.Automation.Configuration'

Rename 'PropertyScope' to 'ConfigScope'

263ec24

Rename file PropertyAccessor.cs to PSConfiguration.cs

6ab1ad7

Refactor GroupPolicy setting related code to use the configuration file

41c66db

Add xUnit tests for reading Policy settings from config file

117e83a

[Feature] Minor changes to make ScriptBlock logging work with SysLog

a6c62bf

daxian-dbw force-pushed the event branch from 87ff37f to a6c62bf Compare January 4, 2018 21:42

SteveL-MSFT reviewed Jan 4, 2018

View reviewed changes

daxian-dbw added the Breaking-Change breaking change that may affect users label Jan 4, 2018

SteveL-MSFT requested changes Jan 4, 2018

View reviewed changes

dantraMSFT suggested changes Jan 5, 2018

View reviewed changes

SteveL-MSFT requested changes Jan 5, 2018

View reviewed changes

Address one of Dan's comments

167bbad

iSazonov reviewed Jan 5, 2018

View reviewed changes

daxian-dbw added the Area-Maintainers-Documentation specific to documentation in this repo label Jan 5, 2018

PaulHigin previously requested changes Jan 5, 2018

View reviewed changes

iSazonov reviewed Jan 5, 2018

View reviewed changes

daxian-dbw added 2 commits January 5, 2018 14:33

Re-enable group policy settings from registry

b4b864f

On windows, group policy settings from registry takes precedence over the configuration file. If a policy is not defined in GP, then we query from configuration file.

Rename 'PowerShellProperties.json' to 'powershell.config.json'

3b5badc

dantraMSFT suggested changes Jan 6, 2018

View reviewed changes

dantraMSFT reviewed Jan 6, 2018

View reviewed changes

[Feature] Change two methods to use 'private' modifier.

3b94173

TravisEz13 reviewed Jan 6, 2018

View reviewed changes

daxian-dbw mentioned this pull request Jan 7, 2018

The static cache for group policy settings should be cleared when GP settings change #5804

Closed

[Feature] Consider a policy is undefined if none of its properties ar…

6ee608f

…e set

SteveL-MSFT requested changes Jan 8, 2018

View reviewed changes

[Feature] Address Steve's new comments

01ecf4b

SteveL-MSFT added this to the 6.0.0-GA milestone Jan 8, 2018

SteveL-MSFT approved these changes Jan 8, 2018

View reviewed changes

dantraMSFT approved these changes Jan 8, 2018

View reviewed changes

TravisEz13 approved these changes Jan 8, 2018

View reviewed changes

daxian-dbw merged commit d261e1f into PowerShell:master Jan 8, 2018

daxian-dbw deleted the event branch January 8, 2018 20:03

TravisEz13 mentioned this pull request Jan 9, 2018

Merge 6.0.0-ga PRs #5828

Merged

daxian-dbw mentioned this pull request Jan 22, 2018

Fix group policy cache #2877

Closed

dantraMSFT mentioned this pull request Jan 31, 2018

Powershell 6.0.0-1.debian.9 logging to /var/log/syslog is too verbose... #6032

Closed

sdwheeler mentioned this pull request May 2, 2018

Add example json config file to about_Logging topic MicrosoftDocs/PowerShell-Docs#2391

Closed

8 tasks

daxian-dbw mentioned this pull request Dec 14, 2018

Add about_PowerShell_Config MicrosoftDocs/PowerShell-Docs#3238

Merged

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make PowerShell able to enable logging of script block execution on Unix platforms #5791

Make PowerShell able to enable logging of script block execution on Unix platforms #5791

		@@ -921,7 +921,7 @@ internal static TranscriptionOption GetSystemTranscriptOption(TranscriptionOptio
		{
		if (systemTranscript == null)

Make PowerShell able to enable logging of script block execution on Unix platforms #5791

Make PowerShell able to enable logging of script block execution on Unix platforms #5791

Conversation

PR Summary

An example of the configuration file powershell.config.json

Limitation that needs to be documented

Documentation needed

PR Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

An example of the configuration file `powershell.config.json`