The first preview of Microsoft's new Operating System, internaly codenamed "Windows 8" by Julie Larson-Green, Corporate Vice President, Windows Experience.
Today's article is about configuring Exchange receive connectors with specific certificates. Out of the box, Exchange uses self signed certificates to provide TLS secured mail flow. This will definitely be an issue if you expose the SMTP protocol to client computers since they won't trust the certificate. In this article we are going to configure a certificate that was issued by a third part authority to the Client Frontend receive connector. We'll start with getting the thumbprint of the certificate using the Get-ExchangeCertificate cmdlet: [PS] C:\> Get-ExchangeCertificate Thumbprint Subject ---------- ------- 241B864DC82C664FECBA18B8D54987AAFB65B4C2 CN=*.lab.com, ... D4D210886B34E690191A1F008C78FDD0E7325DD4 CN=Exchange2013A 960171662EB261162F9C8CBE12E0B75D6F06ABB0 CN=Microsoft Exchange Server Auth Certificate 2690324B827A9F2B75D59104F81CAAA57CDD627B CN=WMSvc-Exchange2013A [PS]
In most cases, the scripts, functions and cmdlets we develop have to save events to a log file to make troubleshooting easier. With PowerShell, the easiest thing would be to write an event to the event log or a file. When it comes to centralized log management, most organizations have based their strategy on the syslog server and protocol. There may be agents on the windows server machines that your code is running on to collect the messsages but that's not always the case. So how can we send messages to a syslog server directly using PowerShell? Although that's not that hard, I've put together a cmdlet to do just that! My General PowerShell module that is published on the Gallery contains the Send-SyslogMessage cmdlet from version 2.12.0 onwards. A call to the Send-SyslogMessage would be pretty much like the following: Send - SyslogMessage - Server syslog . lab . local ` - Severity Error ` - Facility Local0 `
A couple of weeks back, a certificate was approaching it's expiration date on an IIS server and the update - although pretty straight forward, caused a major issue for the service running on that server. I had the new certificate in PFX format, I've installed it on the computer certificate store and it was available in the IIS Manager console. All the certificates for the Root and Intermediate authorities were property installed and the clients had access to the CRL urls. However, when I switched the certificate, the clients were not able to communicate property with the website. After going through the logs on the clients and the application, I discovered that the clients were using client certificates in order to authenticate and the validation process was failing for those certificates since my server could not check their revocation. I opened up a command prompt to get more information on the bindings on the website since there are settings that are not available when