2020年9月28日 星期一

powershell 543

某個目下的檔案要批次更換檔名中的固定位置的名稱

get-childitem 'C:\temp' -filter '*.xlsx' | rename-item -newname { $_.name.substring(0,12) +"04.xlsx"} 



2020年9月26日 星期六

送修MAC抱怨和感謝

哥哥有台MAC電腦開不了機,因為在越南送修被告知是電池膨脹造成無法開機,但沒有電池現貨可換,剛好他又要回台灣,所以我就給拿去StudioA站前店送修。

一開始店員先是告知檢測後若決定要修理可折抵1200的檢測費,我是沒啥概念,1200也就給開下去了。

隔天StudioA打電話來,說檢查結果電池確實膨脹,但有經過一連串檢測後發現主機板也壞了,所以整個修理起來要花26000元。

哇咧,恁祖媽用電腦20多年,也沒發生過電腦被操到往生如這般狀態連主機板都要換.....

這不是重點,重點是後來我決定不修,爬了文,大家都說要送修到坊間小店試看看,也許不會那麼嚴重,畢竟主機板是電腦的中樞,換了還不如買台新的,而且我真的也不太相信APPLE的主機板有那麼不堪。

於是乎,拖了幾天,上網找一家離家比較近的,首先跳出來是這家FixTED蘋果維修工作室。看了GOOGLE星星4.8顆星評論也挺好,且週日也有營業很符合我的時間,所以就直接公車前往。

台北市文山區羅斯福路六段163號 

外面下著小雨,我收好我的YELLOW SNOOPY傘(這我很寶貝得要收好..免得被幹走,哈哈)

一進門,只看到一個年輕小帥哥在工作桌前對一台脫了外殼的MAC AIR在做事,裡頭都沒人。

大概描述了一下狀況,他很俐落的開始進行檢測。先是用MAC內建的檢測工具測試,只顯示電池問題。所以他也幫這台MAC脫了外殼,一打開,我的老天鵝,電池仿佛快要炸開一樣鼓鼓的一片。

 


老板很阿莎力的拿了一盒新開封電池做測試,他是那種很果決的拿出來,也沒有先問我什麼,然後就把電池先接好,又再重新測試一次開機,接著MAC就很順的進到登入畫面了。然後對我說,電池換了就好。

我當然不等他問,就說直接換了電池,10分鐘後,這台MAC就活過來了。

過程中,和老板小聊了一下StudioA,和網路上的網友說的一樣,送去這種RESELLER維修真的只有一肚子氣和大便,因為裡面的流動率太高了,3個月算資深。所以送修時,要嗎就送直營店(101附近那二家),要嗎就找坊間的來修就好,根本也不用什麼檢測費,也不用換貴森森的主機板。

因為我本來相信StudioA是Apple Premium Reseller,應該有品質保證,不管是人員或服務。但經過這一次,我想我再也不會去非直營店了。在保固內就直送直營店,保固外,我就選這家坊間小店就好了。

真心推薦,也許檢測和換電池不是什麼大工程,但老板對客戶的態度和小店一進去給人的感覺才是令我物超所值的 心情美麗的點。

話好好說耐心地說真的很重要,學習之。


那天我一進門後,沒幾分鐘,陸續來了3個客人,有2個都是MAC AIR電池的問題。電池會變胖真的有那麼容易嗎? 

我是windows筆電的愛用者,工作上也沒法用MAC做事,但每次經過咖啡店幾乎都是一排年輕男女都是在用MAC,我只覺得假掰有餘文青不足啦,哈哈。

 

把MAC帶回家後,要reset掉重安裝,爬文看了一下文章,但我卻被卡了2個小時,大部份原因是因為習慣於windows的重安裝過程,MAC安裝讓我百般不適,光鍵盤就手忙腳亂的,哈哈。

最後終於清除了硬碟開始重安裝後,雖然有照著官網說的在顯示地球轉動的圖示選了語言後,但要安裝的OS版本仍是10.11版的而不是最新的版本?

反正也不管了,安裝的是OS X El Capitan, 10.11,但跑到一半時出現沒有可安裝的合格套件

又花了點時間爬文,應該是系統時間太新無法安裝舊版本的OSX,解決方法是得要進入終端機更改系統日期時間,所以找到終端機進入後輸入以下指令 date 070512052016.03,然後重開機再跑一次,結果試了二次還是不行,看起來日期時間又被改回來。

我想是因為開機後連網的關係,日期時間又被校正回來了,我一時間又找不到關閉無線網路的方式,只好將ROUTER關掉讓MAC無法連網,最後終於完成安裝了。

 

 

windows 2016 套用GCB 政府組態基準543

 政府單位近年對資安要求日益嚴格,不管是主機還是AP面都花了大錢買了一般人買不起的工具在監控稽核,但小廠商怎麼可能有預算先花幾百萬買黑白箱掃瞄或主機稽核工具,然後再每年花幾百萬買MA呢?一個專案的預算也就幾百萬甚至不到百萬,哪裡買得起。所以免費的開源的都要不斷的找尋找尋再找尋,呵呵。

最近弄了幾台windows 2016的GCB套用(https://www.nccst.nat.gov.tw/GCB),以前一直不想套用,大概就將主機升級到更新的OS版本,因為無GCB可套用,所以也就當視而不見的免了這些 稽核。但終究不是辦法,該面對的還是得要面對,

現在套用後,遇到了一些問題。

1.無法遠端登入,因為GCB禁止本機帳戶進行遠端登入。為了測試方便,先手動開啟。

 gpedit.msc>Windows設定>安全性設定>本機原則>使用者權限指派>拒絕本機登入移除本機帳戶即可。

2.原系統中有使用於不相容FIPS容許的演算法都會顯示此『實作不屬於 Windows Platform FIPS 已驗證密碼編譯演算法的一部分』,因為gpedit.msc>Windows設定>安全性設定>本機原則>安全性選項>『系統密碼編譯:使用FIPS相容演算法於加密,雜湊,以及簽章』啟用。

這個就AP面將有使用加解密的演算法調整符合FIPS規定 ,例如MD5加密改寫使用SHA256以上。

但有個很老很老的系統,是用VS2005 net framework 2.0開發,主要是讀ReportServer 上server report(RDL)做報表資料呈現,FIPS問題就將網站升級為 net framework 4.5就解決了。

但可以登入後,在連線到報表伺服器時雖已採用了impersonate 的方式模擬主機使用者做windows驗證。現在套了GCB後,出現以下訊息

An exception of type 'System.Net.WebException' occurred in Microsoft.ReportViewer.Common.dll but was not handled in user code

Additional information: 要求失敗,HTTP 狀態 401 : Unauthorized。

System.Net.WebException was unhandled by user code
  HResult=-2146233079
  Message=要求失敗,HTTP 狀態 401 : Unauthorized。
  Source=Microsoft.ReportViewer.Common
  StackTrace:
       於 Microsoft.SqlServer.ReportingServices2005.Execution.RSExecutionConnection.GetSecureMethods()
       於 Microsoft.SqlServer.ReportingServices2005.Execution.RSExecutionConnection.IsSecureMethod(String methodname)
       於 Microsoft.SqlServer.ReportingServices2005.Execution.RSExecutionConnection.LoadReport(String Report, String HistoryID)
       於 Microsoft.Reporting.WebForms.ServerReport.GetExecutionInfo()
       於 Microsoft.Reporting.WebForms.ServerReport.GetParameters()
       於 newMOJBIS._default.Page_Load(Object sender, EventArgs e) 於 ...\default.aspx.vb: 行 20
       於 System.Web.UI.Control.OnLoad(EventArgs e)
       於 System.Web.UI.Control.LoadRecursive()
       於 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
  InnerException:


 但直接用模擬的windows帳號登入ReportServer卻是沒有問題,可正常顯示報表資料。

 至今尚未找到解決方式.........待續

 

 

2020年9月10日 星期四

允許一般使用者使用openrowset

如果要匯入外部檔案資料會使用 openrowset方式,匯入excel(xls、xlsx)、csv、txt都可以,使用前先安裝AccessDatabaseEngine.exe (64位元SQL SERVER請下載64bit)

再執行以下TSQL指令

USE [master]
GO
 
EXEC master . dbo. sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.16.0' , N'AllowInProcess' , 1
GO

EXEC master . dbo. sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.16.0' , N'DynamicParameters' , 1
GO

現有個特殊需求是,建一個唯讀使用者後,執行openrowset有如下訊息

Msg 7415, Level 16, State 1, Line 2
Ad hoc access to OLE DB provider 'Microsoft.ACE.OLEDB.16.0' has been denied. You must access this provider through a linked server. 


select  * from openrowset('Microsoft.ACE.OLEDB.16.0','Text; HDR=NO; CharacterSet=65001;Database=d:\SQLFiles\',
'select * from [test1.txt]')

 

若要開放一般使用者使用,則再執行以下指令(以SQL2019 DB為例)

EXEC master . dbo. sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.16.0' , N'DisallowAdHocAccess' , 1
GO  

再使用regedit到機碼修改DisallowAdHocAccess=0

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.MSSQLSERVER\Providers\Microsoft.ACE.OLEDB.16.0]

 
如果讀取的txt、csv delimiter 非逗點相隔,則需在來源檔案同目錄下定義Schema.ini檔,內容如下,例如來源檔名為test1.csv,分隔符號為 !,則Schema.ini需定義如下,若有多個檔名需各別定義在.ini中。

[test1.csv]
ColNameHeader=False
Format=Delimited(!)

[test2.csv]
ColNameHeader=False
Format=Delimited(!)

[test3.csv]
ColNameHeader=False
Format=Delimited(!)
 

publish error allowDefinition='MachineToApplication'

一個老舊的aspx web form專案,調了一些功能建置成功,但進行部署時顯示以下錯誤。 在應用程式層級之外使用註冊為 allowDefinition='MachineToApplication' 的區段發生錯誤。錯誤的原因可能是虛擬目錄尚未在 IIS 中設定為...