Powershell – Truth about default formatting

cmdlet의 default output format에 대하여 자세히 설명되어 있다.
Get-Process, Get-Service, Get-WmiObject의 출력 형식이 다른 이유에 대한 내용이 기술되어 있다.

Manjunath Rao

Have you ever ran a powershell cmdlet and stare at the output, and ever wondered, what makes Powershell display the results in such a way? Is there any hidden configuration that guides the powershell engine to display results in a specific format for one cmdlet and in a different format for another cmdlet??

Read along. This blog will answer your curiosity !

Example: Below is the output of Get-service


Below is the output of Get-Process


The answer is Yes. The Powershell Engine is indeed guided by a configuration file that tells powershell on how to display the results. Or we call it as the “Default rules for Formatting” (not an official name :))

You will find the configuration files in the Powershell Installation Folder. Use the “$pshome” variable to find out the Powershell Installation Folder.

PS E:WorkPowershellscripts> $pshome

Change the directory to the Powershell Installation directory and you must be…

View original post 646 more words

Test Website SSL Certificates Continuously with PowerShell and Pester

Test Website SSL Certificates Continuously with PowerShell and Pester

유용한 Module이네…

PowerShell, Programming and DevOps

One of the most common problems that our teams deal with ensuring that SSL certificates are working correctly. We’ve all had that urgent call in telling us that the web site is down or some key API or authentication function is offline – only to find out it was caused by an expired certificate.

An easy way of preventing this situation would have been to set up a task that continuously tests your SSL endpoints (internal and external web apps and sites, REST API’s etc.) and warns us if:

  • The certificate is about to expire (with x days).
  • The SSL endpoint is using safe SSL protocols (e.g. TLS 1.2).
  • The certificate is using SHA256.

This seemed like a good task for Pester (or Operation Validation Framework). So, after a bit of digging around I found this awesome blog post from Chris Duck showing how to retrieve the certificate…

View original post 606 more words

Workgroup 환경에서 공유 폴더에 액세스가 안되는 이유

모든 컴퓨터가 도메인이 아닌 작업그룹에 속해 있으면서 똑같은 사용자 계정과 암호를 사용함에도 \\원격컴퓨터이름 으로 접속이 안되는 것은 네트워크 카드의 프로파일 설정이 다르게 되어 있기 때문이다.
기본 설정은 Public(공용)으로 되어 있는데, 어떤 컴퓨터는 Private(개인)으로 되어 있고, 다른 컴퓨터는 Public(공용)으로 되어 있으면 원격 컴퓨터의 공유 폴더에 접속할 수 없다.
또한 작업그룹 환경하에서 Powershell로 원격 잡속을 하기 위해서는 반드시 Private로 설정되어 있어야 한다.
다음과 같이 설정하면 된다
Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private
이제 원격 컴퓨터의 공유 폴더에 접속하면 된다

작업그룹(Workgroup) 환경에서 PowerShell Remoting(파워쉘 원격 관리) 하기

도메인 환경이 아닌 작업그룹 환경에서 파워쉘로 원격 컴퓨터에 접속하려고 하면 실패한다.
그 이유는 1)인증 문제와 2)서비스 시작 문제 그리고 3)네트워크 카드의 프로파일 문제 때문이다.
도메인 환경에서는 이 3가지 문제가 동시에 해결되기 때문에 문제가 없다.
[접속을 허용하는 서버 쪽 설정하기]
Enable-PSRemoting -Force
Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private
[접속을 하는 클라이언트 쪽 설정하기]
Enable-PSRemoting -Force
Set-Item WSMan:\localhost\client\TrustedHosts -Value *
Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private
[원격 컴퓨터에 접속하기]
Test-WSMan remotecomputername
Enter-PSSession -ComputerName remotecomputername

Azure VM을 HTTPS (5986 포트)로 안전하게 원격 관리하기

PowerShell을 사용하여 원격 컴퓨터를 관리하는 것을 Remoting이라고 한다. 주로 Enter-PSSession 및 Invoke-Command도 작업을 하는데, 이 때는 http인 5985 포트를 사용한다. 이것을 사내 네트워크에서나 Active Directory 환경에서 적합하다. 그 이유는 고립된 네트워크에서는 http로 통신하는 것으로 충분하다.

하지만 Azure VM을 PowerShell로 관리하려면 Internet으로 접속해야 하므로 보안을 위해서 https로 접속하는 것이 좋다. 이를 위해서는 아래와 같이 작업을 하면 된다.
Azure VM에서 작업하기 위해서는 Azure VM에 5986 포트를 방화벽에서 예외 처리할 뿐아니라, Network Security Group에서도 5986 포트를 예외 처리를 해주어야 한다.