The PowerShell script to purge Exchange Server and IIS log files has been updated to version 2.1.
The function Copy-LogFiles has been slightly rewritten and there has been a change in the cmdlet parameters.
When using ArchiveMode CopyAndZip or CopyZipAndDelete all copied log files in the EXCHANGESERVER\LOGS folder are added to a compressed archive. The script creates a separate archive for IIS and Exchange logs.
Code updated
function Copy-LogFiles { [CmdletBinding()] param( [string]$SourceServer, [string]$SourcePath, $FilesToMove, [string]$ArchivePrefix = '' ) if($SourceServer -ne '') { # path per SERVER for zipped archives $ServerRepositoryPath = Join-Path -Path $RepositoryRootPath -ChildPath $SourceServer # subfolder used as target for copying source folders and files $ServerRepositoryLogsPath = Join-Path -Path $ServerRepositoryPath -ChildPath $LogSubfolderName $ServerRepositoryPath = Join-Path -Path $RepositoryRootPath -ChildPath $SourceServer if(!(Test-Path -Path $ServerRepositoryPath)) { # Create new target directory for server, if does not exist $null = New-Item -Path $ServerRepositoryPath -ItemType Directory -Force -Confirm:$false } foreach ($File in $FilesToMove) { # target directory $targetDir = $File.DirectoryName.Replace($TargetServerFolder, $ServerRepositoryLogsPath) # target file path $targetFile = $File.FullName.Replace($TargetServerFolder, $ServerRepositoryLogsPath) # create target directory, if not exists if(!(Test-Path -Path $targetDir)) {$null = mkdir -Path $targetDir} # copy file to target $null = Copy-Item -Path $File.FullName -Destination $targetFile -Recurse -Force -Confirm:$false -ErrorAction SilentlyContinue } if($ZipArchive) { # zip copied log files $Archive = Join-Path -Path $ServerRepositoryPath -ChildPath ('{0}-{1}' -f $ArchivePrefix, $ArchiveFileName) $logger.Write(('Zip copied files to {0}' -f $ArchiveFileName)) # delete archive file, if already exists if(Test-Path -Path $Archive) {Remove-Item -Path $Archive -Force -Confirm:$false} try { # create zipped asrchive Add-Type -AssemblyName 'System.IO.Compression.FileSystem' [IO.Compression.ZipFile]::CreateFromDirectory($ServerRepositoryLogsPath,$Archive) } catch { $logger.Write(('Error compressing files from {0} to {1}' -f $ServerRepositoryLogsPath, $Archive),3) } finally { # cleanup, if compression was successful if($DeleteZippedFiles) { $logger.Write(('Deleting folder {0}' -f $ServerRepositoryLogsPath)) $null = Remove-Item -Path $ServerRepositoryLogsPath -Recurse -Force -Confirm:$false -ErrorAction SilentlyContinue } } } } }
This script converts Word compatible documents to a selected format utilizing the Word SaveAs function. Each file is converted by a single dedicated Word COM instance.
The script converts either all documents in a single folder of a matching an include filter or a single file.
Currently supported target document types:
The conversion is handled by Word itself, utilizing the SaveAs method.
The Word.Document.SaveAs method supports the following wdFormat values:
Implemented document formats are shown in bold.
# EXAMPLE # Convert all .doc files in E:\temp to Default .\Convert-WordDocument.ps1 -SourcePath E:\Temp -IncludeFilter *.doc # EXAMPLE # Convert all .doc files in E:\temp to XPS .\Convert-WordDocument.ps1 -SourcePath E:\Temp -IncludeFilter *.doc -TargetFormat XPS # EXAMPLE # Convert a single document to Word default format .\Convert-WordDocument.ps1 -SourcePath E:\Temp\MyDocument.doc
When you run software solutions that make use of TLS secured communication channels the applications need to have access to the certificate's private key. The private key is part of the certificate stored in the local certificate store of the computer. In most cases the software solution creates a new self-signed certificate and configures access rights appropriately.
When establishing TLS communication channels to external partners, the use of a public SSL/TLS certificate is a must have requirement.
The following step-by-step instructions describe how to assign Read permisson for the Email Security Solution Gateway NoSpamProxy. In this case the solution does not utilize a classic service account, but a so-called virtual service account. Virtual service accounts provide a much better access security when executing Windows services.
Open the local computers certificate store using the MMC Snap-Ins.
Select the certificate to use and open the context menu (right click).
Select Manage Private Keys to manage the private key permissions.
Click Add and add the required service accounts.
In this case the virtual service accounts are part of the local computer entity. Select the local computer and not the Active Directory domain as source when searching accounts. Virtual accounts us the prefix NT Service.
Add the follow accounts to configure read access for NoSpamProxy on a server having the Gateway and Intranet role installed.
NT Service\NetatworkMailGatewayIntranetRole NT Service\NetatworkMailGatewayManagementService NT Service\NetatworkMailGatewayGatewayRole NT Service\NetatworkMailGatewayPrivilegedService
Add the follow accounts to configure read access for NoSpamProxy on a server having the Gateway role installed only.
NT Service\NetatworkMailGatewayManagementService NT Service\NetatworkMailGatewayGatewayRole NT Service\NetatworkMailGatewayPrivilegedService
Click Check Names to verifiy the existence of the entered service accounts.
When correctly resolved the accounts names are replaced by theis respective display names. Click OK to add the accounts.
Configure read access for all added service accounts and click OK.
The software solution is now capable of accessing the private key of the certificate.
The SMTP Simulator project has been started due to a specific demand during a customer project. We needed a solution to test native transport of Exchange Server 2013 and third party addons to Exchange in an isolated lab envrionment having no internet access at all.
While it is pretty easy to send test emails using PowerShell, we wanted to create an automated service which is capable of:
The SMTP Simulator can be used with any Message Transfer Agents (MTA), not only with Exchange. Besides testing the MTA itself, we needed to test some of the following third-party solutions:
The Visual Studio solution creates a MSI installer file. The MSI package created installs the SMTP Service itself, but not the required web application (see issue #49).
Documentation is provided by the SMTP Simulator Wiki.
The code has been published as open source at Github. Feel free to fork the solution and contribute to the code.
Report any issues or feature requests at Github.
The project still has some open ends and needs some love and attention. Open issues are part of the issue tracker at Github.
Main topics are:
The GlobalFunctions PowerShell module has been updated to support writing of log messages to the PowerShell output pipeline.
When writing to the PowerShell output pipeline, the severity level is not written to the pipeline. In most cases you will use this option for debugging purposes.
# Import module first Import-Module -Name GlobalFunctions # Create an instance of the logger $ScriptDir = Split-Path -Path $script:MyInvocation.MyCommand.Path $ScriptName = $MyInvocation.MyCommand.Name $logger = New-Logger -ScriptRoot $ScriptDir -ScriptName $ScriptName -LogFileRetention 14 # Write an informational message to the log file only $logger.Write('Some informational message') # Write an informational message to the log file only $logger.Write('Some message to log and console',0,$true) # Write a warning level message to log file and the message only to PowerShell output pipeline $logger.Write('Some warning message',2,$true)
Remember to add the severity level when writing to console.
Read more about the GlobalFunctions module here.
You can get the source code here: