Added new post

Author: Daniele Catanesi

_posts/2022-01-25-Cannot bind argument to parameter-Token-Expiry.md

@@ -1,57 +1,46 @@
 ---
-title: "Cannot bind argument to parameter TokenExpiryTime because it is null - Error Message"
-excerpt: "When opening a PowerShell session to both on-prem and Exchange online in the same window cannot bing argument to parameter TokenExpiryTime because is null error message could be displayed. Let's explore how to solve this."
+title: "PowerShell - Get day of weekday"
+excerpt: "In this short post we will see how we can use PowerShell to get an integer representing the number associated with the day of the week for the current date."
 categories:
   - PowerShell
-  - Exchange
-  - Office 365
+  - Howto
 
 tags:
   - PowerShell
-  - Office365
-  - Exchange
+  - Tips
+  - HowTo
 
 toc: true
 header:
   teaser: "/assets/images/PowerShell_Logo.png"
 ---
 
-## Exchange Online Certificate Based authentication
+## PowerShell Get current date
 
-Microsoft is, _finally_, disabling **basic authentication** (read username and password) in Exchange Online in favor of **Certificate Based authentication**.
+PowerShell natively supports getting the current, or specific, date via the following cmdlet:
 
-Once this change is fully implemented, around mid February at least for some tenants, connecting via username and passwords to Exchange Online will not be possible anymore.
-
-You can read my article on how to implement _Certificate Based authentication_ for Exchange Online [here](https://pscustomobject.github.io/powershell/office365/exchange/Exchange-Online-Certificate-Based-Authentication/).
-
-As a result of this change I started updating one of our automations, responsible for the whole life-cycle of our mailboxes, to ditch old credential objects in favor of the more secure Certificate Authentication.
-
-This is when I encountered the _cannot bind argument to parameter 'token expiry time' because it is null._ error message.
-
-## Multiple PowerShell Exchange Sessions
-
-When operating an hybrid environment it is pretty common to open, in the same window/session, a PowerShell connection to both Exchange on-prem and Exchange Online.
+```powershell
+Get-Date
+```
+Which, by default, will produce the following output:
 
-This is required as part of the configuration, usually creation of the mailbox, takes place in on-prem for example via the _New-RemoteMailbox_ cmdlet while other parts of the configuration are performed directly online for example when delegating mailbox permissions. 
+```powershell
+Monday, February 21, 2022 10:11:39 PM
+```
 
-While debugging my workflow I have noticed that, while trying to retreive mailbox information from the on-prem server, an exception was being thrown
+Cmdlet supports methods which can be used to display/return the day of the week for the selected date
 
 ```powershell
-# Cmdlet I was running
-Get-RemoteMailbox -Identity $userUpn
-
-# Part of the exception message
-Cannot bind argument to parameter 'token expiry time' because it is null.
+(Get-Date).DayOfWeek
 ```
 
-It took me a bit to figure this out as no exception was thrown during the connection *phase* either nor there was any other obvious pointer.
+There are situations where rather than returning a string with the day name it can be useful to return the **number** (1 to 7) associated with the day's name, this can easily be accomplished with the following command
 
-When I was about to give up and open a ticket with Microsoft, which is usually as helpful as freezer in the North Pole, I discovered that establishing a connection to Exchange Online followed by a connection to the on-prem server was yielding the desired result. In my workflow I had this the other way around, first local Exchange and then Online service, which was causing the issue.
-
-**Note:** I have experienced/tested this with version 2.0.4 and 2.0.5 of Exchange Online PowerShell module but other versions could be affected as well.
-{: .notice--warning}
+```powershell
+(Get-Date).DayOfWeek.value__
 
-I did not dig deep into the root cause of the issue but plan to do this tomorrow and already sent my feedback to exocmdletpreview {at} service {dot} microsoft {dot} com but I doubt I will hear anything from that channel. 
-I will anyhow open a ticket with support to at least have an official statement/clarification on this.
+# Output
+1
+```
 
-As soon as I have any news I will update the post until then I hope you can find the information useful.
+This is specially handy when inserting data into SQL datbase supporting dates as *TinyInt* data types.

_posts/2022-02-22-PowerShell-Get-Weekday.md

@@ -0,0 +1,70 @@
+---
+title: "Exchange Online Management Module - Could not use the certificate for signing"
+excerpt: "When trying to establish a connection to Exchange Online Could not use the certificate for signing error message is displayed."
+categories:
+  - PowerShell
+  - Exchange
+  - Office 365
+
+tags:
+  - PowerShell
+  - Office365
+  - Exchange
+
+toc: true
+header:
+  teaser: "/assets/images/PowerShell_Logo.png"
+---
+
+## Exchange Online Certificate Based authentication
+
+As I have written in my [previous post about TokenExpiry error message Microsoft is retiring ability to connect to Exchange Online via basic authentication](https://pscustomobject.github.io/powershell/exchange/office%20365/Cannot-bind-argument-to-parameter-Token-Expiry/).
+
+You can read my article on how to implement _Certificate Based authentication_ for Exchange Online [here](https://pscustomobject.github.io/powershell/office365/exchange/Exchange-Online-Certificate-Based-Authentication/).
+
+## Could not use the certificate for signing error message
+
+Today while I was updating code for one of our automations I created a request for a new certificate to use for authentication purposes. 
+
+Once I deployed code to our test environment automation was failing the connection to Exchange Online with the following error
+
+```powershell
+[System.Management.Automation.RuntimeException] One or more errors occurred.
+[Microsoft.Identity.Client.MsalClientException] Could not use the certificate for signing. See inner exception for details. Possible cause: this may be a known issue with apps build against .NET Desktop 4.6 or lower. Either target a higher version of .NET desktop - 4.6.1 and above, or use a different certificate type (non-CNG) or sign your own assertion as described at aka.ms/msal-net-signed-assertion.
+[System.Security.Cryptography.CryptographicException] Invalid provider type specified.
+````
+
+Funnily enough the same certificate and cmdlets were working fine with PowerShell 7. 
+
+After quite some troubleshooting I've found out the problem was caused by the certificate's private key using [*Cryptography Next Generate (CNG)*](https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/network/cng-certificates-overview) template rather than RSA. 
+
+Not having direct access to the CA releasing the certificate I could not change this so I had to resort on either running the automation in PowerShell 7 or update the certificate itself. 
+
+Luckily this is easily done via OpenSSL. Let's see how.
+
+## Convert Certificate private key from CNG to RSA
+
+If you have installed Git, cygwin or Windows Subsystem for Linux you just need to fire a bash prompt and use the following commands:
+
+```bash
+# Extract the public key from the cert 
+OpenSSL pkcs12 -in "CNGCertificate.pfx" -nokeys -out "temp.cer"
+
+# Extract the private key
+OpenSSL pkcs12 -in "CNGCertificate.pfx" -nocerts -out "temp.pem"
+
+# Convert key to RSA
+OpenSSL rsa -inform PEM -in "temp.pem" -out "temp.rsa"
+
+# Finally create a new pfx file
+OpenSSL pkcs12 -export -in "temp.cer" -inkey "temp.rsa" -out "RSACertificate.pfx"
+````
+
+**Note:** In the above commands I am not using a password for the certificate as everything is local to my machine but a password is definitely *required* when exporting a certificate together with the private key.
+{: .notice--warning}
+
+Once the new pfx file has been created all *temporary* certificates can be safely removed form the system and connection to Exchange Online will go through just fine. 
+
+Again if you can use PowerShell 7 you will not face this issue but in case you're stuck with version 5.1 and facing this error message hopefully this post can save you some headaches. 
+
+Full credit for the solution goes to this [StackOverFlow thread](https://stackoverflow.com/questions/22581811/invalid-provider-type-specified-cryptographicexception-when-trying-to-load-pri/34103154#34103154)