powershell CRLF斷行換回LF

 
bcp產出的資料中，若欄位為空會寫入NUL，故利用powershell將NUL置換掉。

但因檔案是要給linux系統使用，故原本bcp產出的資料是以LF斷行，但經過powershell處理後，會自動將斷行符號換成CRLF。

所以改寫ps檔如下，最後再還原LF斷行.....一波好幾折...

 ((Get-Content c:\temp\test.txt)  -join "`n") + "`n"| ForEach-Object { $_ -replace "`0", "" } | Set-Content -NoNewline c:\temp\test.new
 

稽核失敗eventid 4625 msmdsrv.exe

主機事件檢視器在dimension或cube process時，一直不斷出現安全性下的稽核失敗。造成3分鐘內20筆稽核失敗被視為資安警認通報，訊息摘要如下：

帳戶無法登入

登入失敗的帳戶

安全性識別碼：NULL SID

帳號名稱：admin

帳號網域：TESTBI

失敗原因：未將這台機器上要求的登入類型授與使用者。 

The user has not been granted the requested logon type (aka logon right) at this machine

登入類型：8

呼叫者理程序名稱： "C:\Program Files\Microsoft SQL Server\MSAS15.SQL2019\OLAP\bin\msmdsrv.exe"

依照登入類型=8，查到NetworkCleartext 使用者從網路登入此電腦。 使用者的密碼已傳遞至其未顯示表單的驗證套件。 內建的驗證會先封裝所有雜湊認證，再傳送給整個網路。 認證不會以純文字或純文字 (稱為 cleartext) 。

但並無任何排程有使用到明碼作認證?而且OLAP查詢或處理也都很正常?

找了好久，最後在OLAP 資料庫的資料來源中看到安全性設定，原本使用ImpersonateAccount 以系統帳號做認證，不知為何，在此台主機如此設定就會有eventid 4625 稽核失敗的紀錄，但另外一台主機同樣的設定則沒有問題。

將模擬資訊改為繼承後，重新處理dimension或cube，事件檢視器就再無稽核失敗問題了。