Christos Polydorou

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 `

In the era of the cloud, service releases and changes are nearly constant. Microsoft Office 365 could not be an exception, especially with the large and increasing number of services and millions of users. But some of those changes and releases sometimes cause issues with on-premises infrastructure that is not property configured. Today I am going to focus on the networking side of things and talk about allowing access to Office 365 services from firewall and proxy servers. The first thing you'll need to permit access to Office 365 services from your on-premises machines is to know the service endpoints and by endpoints I mean IP addresses and URLs. Fortunatelly, this information is available from Microsoft in this   article so the only thing you'll have to do is read through it, get the information for the services you're using and configure your proxy server and firewall. That's easy, what happens though when that information is updated? This is where the problems sta