SecretManagement preview 6 and SecretStore preview 4

This post was originally published on this site

Two updated preview releases are now available on the PowerShell Gallery:

For more information on these modules check out these previous blog posts:

Before installing these modules, please uninstall the current preview versions of the modules and restart your PowerShell session.

To install these updates run the following commands:

Uninstall-Module Microsoft.PowerShell.SecretManagement -Force 
Uninstall-Module Microsoft.PowerShell.SecretStore -Force 
# Restart your PowerShell session 
Install-Module -Name Microsoft.PowerShell.SecretManagement -AllowPrerelease -Repository PSGallery 
Install-Module -Name Microsoft.PowerShell.SecretStore -AllowPrerelease -Repository PSGallery 
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault -AllowClobber

SecretManagement preview 6 updates

This update to SecretManagement improves the compatibility of the module with Windows PowerShell, and improved the usability of the module by providing more ways to unregister vaults and by setting the first registered vault as default as well a few other changes. Read the full list of changes below:

  • Improved compatibility with Windows PowerShell 5.1 (Issue #73)
  • The first extension vault added will automatically be designated the default vault (Issue #61)
  • Unregister-SecretVault -Name property now supports string[] type and wild cards (Issue #57#58)
  • Register-SecretVault now checks -VaultParameters hashtable for reserved Verbose entry and throws error if found
  • Set-DefaultVault now has a -ClearDefault parameter that designates no registered vault as the default vault
  • Register-SecretVault now supports a -Description parameter and registration information will include an optional extension vault description (Issue #46)

SecretStore preview 4 updates

This update to SecretStore focuses on updates which improve the compatibility with Windows PowerShell. Read the full list of changes below:

  • Improved compatibility with Windows PowerShell when creating new store files (Issue #28)
  • SecretStore binary is now built against net461 to provide full compatibility when run in PowerShell 6 or Windows PowerShell
  • System.IO.FileSystem.AccessControl.dll is now shipped with module to maintain compatibility with Windows PowerShell

Finding other available extension Vaults

To find other SecretManagement extension vault modules, search the PowerShell Gallery for the “SecretManagement” tag. Some community vault extensions that are available:

Thank you to everyone who has created vaults thus far!

Feedback and support

Community feedback has been essential to the iterative development of these modules. Thank you to everyone who has contributed issues, and feedback thus far! As we approach General Availability, targeted for later this year, for these modules now is the time to test the modules against your scenarios to request changes (especially breaking ones) and discover bugs. To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository. For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.

Sydney Smith

PowerShell Team

The post SecretManagement preview 6 and SecretStore preview 4 appeared first on PowerShell.

Announcing PowerShell 7.1

This post was originally published on this site

We’re proud to announce the release of PowerShell 7.1, the latest major update to PowerShell 7. This release includes a number of improvements and fixes that build on top of the PowerShell 7.0 release in March and the recent GA release of .NET 5. Since then, the PowerShell Team (and many of you, our community contributors, thank you!) have been hard at work addressing some of the community’s top bug reports and feature requests.

What’s new in PowerShell 7.1?

For PowerShell 7.1, we decided to build on the foundation established in PowerShell 7.0 with a strong focus on community issues, especially where we could make additive changes and quality-of-life improvements without introducing instability or breaking changes. As a platform with over 115 million sessions per month, we’re absolutely committed to ensuring that PowerShell remains a stable and performant platform, even after significant version upgrades like 7.1.

For more details about what’s been added and fixed, make sure to check out the PowerShell 7.1 release notes.

Where can I get the latest version?

Our latest releases can always be found within the GitHub Releases for PowerShell.

For the first time, on Windows 10, you can also now pick up the latest version of PowerShell on the Microsoft Store.

More information on how to install across various platforms and architectures can be found at https://aka.ms/Install-PowerShell.

Why should I upgrade to PowerShell 7?

PowerShell 7 is the modern, cross-platform edition of PowerShell
built on top of .NET 5+ (formerly .NET Core). PowerShell 7 offers cross-platform support on Linux, macOS, and Windows, SSH-based remoting, parallelization, Docker containers, new operators and language features, and a massive long tail of small improvements and bug fixes.

If you’re still primarily a Windows PowerShell user, and you’re interested to learn more about the benefits and mechanics of moving to PowerShell 7, check out this doc on upgrading from Windows PowerShell to PowerShell 7.

What operating systems and distributions does PowerShell 7.1 support?

PowerShell 7.1 supports a wide variety of operating systems and platforms including:

  • Windows 8.1/10 (including ARM64)
  • Windows Server 2012 R2, 2016, 2019, and Semi-Annual Channel (SAC)
  • Ubuntu 16.04/18.04/20.04 (including ARM64)
  • Ubuntu 19.10 (via Snap package)
  • Debian 9/10
  • CentOS and RHEL 7/8
  • Fedora 30
  • Alpine 3.11+ (including ARM64)
  • macOS 10.13+

We also have community support for:

  • Arc Linux
  • Raspbian Linux
  • Kali Linux

Support lifecycle

PowerShell 7.1 is supported under the Microsoft Modern Lifecycle Policy for the same support timeline as .NET 5: currently 3 months after the release of .NET 6 in roughly one year.

This is in contrast to the PowerShell 7.0, an LTS release that will be supported until December of 2022.

For more information on the PowerShell 7 support lifecycle and requirements, check out https://aka.ms/PSLifecycle.

What else has the PowerShell Team been working on?

Over the last 6-12 months, you may have noticed that some of the more interesting new PowerShell Team functionality is being developed outside of the PowerShell repository within the PowerShell GitHub organization. In upholding our commitment to stability within the PowerShell language runtime, we’re doing as much of our fresh and experimental outside of the primary PowerShell project. Most of this work will live on the PowerShell Gallery, but some may eventually find its way back into the PowerShell project once the PowerShell Team is confident that it’s stable enough to reach the high stability bar that PowerShell 7 necessitates.

Some of these other projects and repositories include

Keep your eyes peeled on the PowerShell Team blog and @PowerShell_Team account on Twitter for more updates, previews, and developments on these efforts.

How can I give feedback

Please file issues in the PowerShell repository on GitHub to let us know about any features you’d like added or bugs that you encounter. Additionally, you can join us for the PowerShell Community Call on the 3rd Thursday of every month. The Community Call is a great opportunity to talk directly to the team, hear about the latest developments in PowerShell, and to voice your opinions into ongoing feature design.

And as always, we accept code, test, and documentation contributions in the form of pull requests on GitHub. If you’re interested in helping out on the project, check out our contribution guide.

Until next time!

Joey Aiello
Program Manager, PowerShell

The post Announcing PowerShell 7.1 appeared first on PowerShell.

Updating help for the PSReadLine module

This post was originally published on this site

Updating help for the PSReadLine module

You may have noticed an error message when trying to update the help for the PSReadLine module.

Error updating PSReadLine help

In the example above, I am trying to update help for the PSReadLine module on my Windows
computer. Take a close look at the error message. Notice the spelling of the module name in the
message:

Failed to update Help for the module(s) ‘PSReadline

In PowerShell 6 and higher, the PSReadLine module is spelled with a capital L character. But the
error message is using a lowercase letter.

The root cause of the error

The problem comes from Windows PowerShell 5.1. The version of the PSReadline module that shipped
in Windows PowerShell 5.1 used a lowercase letter in the name. The name of the module was changed
for the release of PowerShell 6. It now uses a capital L in the name.

The Update-Help cmdlet constructs the URL of the CAB file containing the updated help. The URL
path is case-sensitive. The updated help files use the new name with the capital L. PowerShell 6
and higher is installed side-by-side with Windows PowerShell. When you run Update-Help, the cmdlet
attempts to update the help for both versions of PowerShell. The name of the module that
Update-Help uses is based on the name of the folder where the help is stored. For Windows
PowerShell this is C:Program FilesWindowsPowerShellModulesPSReadline.

Note that only the update of help for the Windows PowerShell location is failing.

How to fix this problem

Fortunately the fix is simple. Just rename the folder to
C:Program FilesWindowsPowerShellModulesPSReadLine. To rename this folder, you must be sure to
close all Windows PowerShell sessions to release any open file handles on the directory. Use the
Windows File Explorer to rename the file. If you try to rename the folder from the command line, you
receive the following error message.

Rename-Item: Source and destination path must be different.

Rename module folder

 

The post Updating help for the PSReadLine module appeared first on PowerShell.

NSX-T Declarative API

This post was originally published on this site

I need to use declarative API to perform some automation tasks, for this instance i need to create few segments.

 

Below code is to create just a single segment and i am putting a Patch request to https://nsx-fqdn/policy/api/v1/infra

 

{

 

    “resource_type”: “infra”,

    “children”: [

        {

        “resource_type”: “ChildSegment”,

        “Segment”: {

            “resource_type”: “Segment”,

            “display_name”: “Post01”,

            “id”: “Post01”

                   }

        }     

                ]

}

 

But i get the below error, can anyone please help to get this right
{

 

    “httpStatus”: “BAD_REQUEST”,

    “error_code”: 220,

    “module_name”: “common-services”,

    “error_message”: “Unexpected character (‘“’ (code 8220 / 0x201c)): was expecting double-quote to start field name”

}

DNS

This post was originally published on this site

Hello,

 

Can someone please tell me:

 

I have a text file called ‘Server_IP’ and in that sheet it has all the IPs.

Is there anyway I can script and get the DNS names by doing nslookup of that IPs and get the result in excel sheet (Can save it in D drvie) like below:

 

(Column A)     (Column B)

Server IP         Server Name

Help regarding down sizing a vmware. Hidden snapshot inside? 200 GB

This post was originally published on this site

Dear,

 

I have a vmware machine that has grown to big.

The local folder is about 192 GB

 

If I check the disk inside vmware(win10) the size is 85 GB

From settings there are 200GB allocated.

I think there are a issue regarding snapshot. I did delete snapshots a while
back(from the menu), but I think one off the VMDK files is that file..

 

I have taken a backup off the folder, and when I deleted the disk an re-attached
vmdk file, I was able to boot the old snapshots.

 

Can anybody gives me a hint?

Disk info

Not preallocated

Multipple files

 

Files

Win10.vmdk

 

Win10-00001.vmdk

Win10-00001-s001.vmdk

Win10-00001-s002.vmdk

Etc…

 

Win10-00002.vmdk – This seems to be the running version

Win10-00002-S001.vmdk

Win10-00002-S002.vmdk

  1. Etc.

 

Win10-S001.vmdk

Win10-S002.vmdk

  1. Etc.

 

 

 

 

 

BR

Service failed on vrops

This post was originally published on this site

I was looking at the f5 LB that we have in front of our vrops and noticed 2 of the noes were shown as offline. |Looking ta the health moniter it is using a API call GET /suite-api/api/deployment/node/statusrn

 

When i run those against the two that are shown as offline i get

 

This matches up with want i am seeing in the F5.

 

If i then run the suite-api/api/deployment/node/services/info which all need to be online for the above to go on line i get

 

 

 

All is good except the last one. I cant for the life of me find how to troubleshoot this or any documentation on the agent on the vrops appliance its self. I can fine loads of stuff on remote agents but not this. Anyone any ideas what the command line is to at least try and start it.

 

Edit: vrops 8.2

Advice on server hardware specification

This post was originally published on this site

Hi All,

 

Can I ask for a bit of advice.  I am looking at a HPE Server (ML350 Gen10) for a client (accounting firm) and wondered what specification you would use for the following scenario.

 

1 x VM – Windows Server 2019 / DC and network services / SQL Express running 2 server apps (IRIS and Virtual Cabinet)

– Note: SQL Express has a max database size limit of 10GB

– IRIS Server – Requirements 2 GHZ Processor / 16GB RAM / 300GB disk space

– Virtual Cabinet Server – Requirements 3Ghz Processor / 4GB RAM / 300GB disk space

 

1 x VM – Windows Server 2019 / RDS / 9 users running:

– Sage – Requirements 2Ghz Processor / 8GB RAM / Min 5GB disk space

– IRIS Client – Requirements 3Ghz Processor / 4GB RAM / Min 15GB disk space

– Virtual Cabinet Client – Requirements 2Ghz Processor / 4GB RAM / 150GB disk space

 

The current server is as follows:

– 1 x HP ML350p Gen8 with 24GB RAM / Raid 10 SAS drives

– Vmware ESXi 5.0 (Yes, this definitely should be upgraded)

– Services: DC running the server software detailed above.

 

The current Windows PC’s are as follows:

– i5 or i7 Processor with a minimum 8GB of RAM.  They are never maxed.

 

Any advice on the right specification hardware and the correct VMware licensing would be greatly appreciated.

absent of uploading preconfigured profiles for macOS

This post was originally published on this site

So when i have an preconfigured signed profile downloaded from here step 4 point 1 for macOS I can’t install from terminal any-longer since Apple has removed that option from version 10.15.4. WS1 doesn’t support uploading of profiles for macOS currently, not sure if it’s in the roadmap for future updates though(Jamf has it).

Deploying via mdm is the only solution when having a custom profile(if you don’t wanna install them manually on the device).

 

Does anyone have any inside on this particular issue or a similar and have solved it?

 

/M