黑白禿毛烤玉米

最近同部門的一位女同事(簡稱黑)，個性很好相處，與男朋友(簡稱毛)感情也順利穩定，毛還買了房子在黑的名下，且結婚計畫準備中，工作上也做得還順利，人生一切順利吧，不過不知何時，出現了成咬金，就是女同事的男朋友，出現了一個新的對象(簡稱禿)，另外，同部門前年有位新來的男同事(簡稱白)，似乎有意追求黑，在這兩件事之後，黑漸漸的轉變了‧‧‧‧‧‧

毛批腿禿的事，被黑知道後，黑就很生氣毛，但在毛努力的甜言蜜語之下，黑還是不斷的原諒毛，於是毛就越來越正大光明的與禿走在一起，似乎有意享齊人之福，但黑不願意，但總事原諒。
同時間，白努力追求黑，黑也在白的香甜玉米攻勢下，漸漸的區服，在一起的程度，白除了不能在烤玉米中扮演竹筷以外，差不多能做的都做了吧。
被毛發現後，黑似乎意有所指毛禿事件，表明自己的單純，但也原諒黑之後，給予黑展現火烤玉米的機會，但也是不能扮演竹筷的角色。
就這樣黑白禿毛烤玉米 幾個月之後 ~~~~~ ~

黑在部門內，由於部門內部調整的關係，黑被調整到另一個小組中，由另一位長官所帶領，但由於長官作風與之前的長官不同，於事發現了黑在工作上，並非如之前的順利穩定，在加上需求的相關單位長官，對於成果覺得不滿意，於是黑的工作越來越多聲音產生，但其工作的困難性與複雜度，若以洗澡來比喻，就是要求洗乾淨一樣，仔細洗乾淨，就完成了，不用除毛、漂白，不用消毒淨化等複雜技術，但是黑就是越來越明顯，洗頭不洗臉，洗手不洗腳，或是洗完大個便，不然就是穿衣服洗澡，導致長官不是被罵，就是去罰站擦屁股，就這樣搞了幾個月後~ ~ ~

黑說他要出國一個月，要去歐洲慰勞八國聯軍，要請假一個月，黑為了這次的假，在前兩三個月，不斷的狂加班，不過加班不是真的為了工作，而是為了能夠由加班而換取補休出國，說他壓力超大，歐洲旅遊並不是出去玩，而是去走走，這樣也很辛苦，這樣也實在很奇怪，工作明明就像洗澡洗乾淨一樣，不知到壓力從哪來，再來是出國旅遊，歐洲好幾個國家，花一二十萬，到處去，這樣不叫做出去玩，超級奇怪的想法；而且黑回國之後，一整個月都再說他出國，國外有多好，多人性，多友善，男的有多帥等等，幾乎任何事，都要拿來跟國外比較一番，然後再大力讚揚一翻，接著是數落一翻；而且同事都覺得她在國外有卡到陰，請他去廟拜拜，卻反問說那廟是做什用的？是旅遊景點？他說他信阿們，再請他去找神父，請神父幫幫他，他卻說那個教堂是有名的景點，多少人去拍照，照片多好看之類的，讓想幫她們的同事們，一整個無言，而且工作上也越來越差，就像失去了洗澡的能力一樣，並且根部門以外的人取暖說，我們都不讓他洗澡洗乾淨，都欺負他洗澡洗不乾淨云云。

 話說回來，其實大家都想幫忙黑，只是黑個性與觀念轉變越來越大，把部門內的同仁都當成了敵人，即使有任何想幫他的動作或意見，都被他視為敵意來看，所以都無能為力，個人認為，今天要幫助黑，就只能透過黑的家人，或是請精神科或心裡醫師，才能幫的上黑了，希望黑能回復到那個低調親和的黑，而不是現在這個充滿敵意又滿身是刺的黑！

風櫃嘴

今天第一次上風櫃嘴，過程中無數次想下山，但在走走停停的風雨中，既然來了，就不要放棄，總算是上到風櫃嘴，風超大、霧也超大、能見度大概只有五公尺。

至善路到楓林橋右轉

磁碟可用容量統計表

最近部門內的長官將磁碟可用容量統計表，交待每個月要統計一次，由於報表簡單，且每月要執行，索性就花了兩天的時間，將統計的工作，建立成一個Script 檔案，並自動發E-Mail 向長官報告，經測試，需要WMI功能要開啟，通訊PORT使用DCOM 的 TCP / 135 ，有些伺服器的Windows 防火牆，手動關閉後，WMI服務確與ICS相關，怎麼開PORT都沒有用，若有這種狀況，就要將ICS服務給停用，測試後還蠻順利的，應該可以達到自動報告給長官的功能。

招聘文員

一隻狗逛街時看到一張告示
【招聘文員，須打字，懂電腦，精通兩種語言，均等機會】
狗於是進去應徵，但是被拒絕了。
經理說：『我不能僱用一條狗在公司裡做事』
狗於是指著均等機會的地方表示抗議
經理只好問狗說：
『你會打字嗎？』
狗跑到打字機前打了一封信
經理又問：『你懂得用電腦嗎？』
狗跑到電腦前寫了一個程式且運作無誤
經理又說：『就算你會打字電腦我還是不能僱用你，我需要的人要會說兩種語言』

農場生活

話說有一天，一群大學女生到農場體驗農場生活，農場主人教導大家如何擠牛奶，示範完畢後，便要大家去找牛親自體驗。這時，有一位女生弄了半天，始終只有一點點，看見別人一桶一桶的收集完成並拿去裝罐，於是非常生氣的跑去找農場主人抱怨，說他們家的牛品質相差太多了！

結果農場主人瞄一眼之後，冷冷的說：

算命先生與小姐對白

算命先生與小姐對白：「妳命不好。」
「為什麼？」「因為妳身上帶有凶兆。」
「那我把胸罩 脫了行嗎？」
「不行，妳一脫了凶兆，就會出現 人生的兩個大波。」........

女同學說什麼?

上課了，教室裡一片吵鬧。 老師問：班長！發生了什麼事情？

vb.net中的region區塊在close狀態下無法搜尋內部的字串！？

首先為了讓程式碼看起來簡潔，

所以我用了#region ....... #end region的區塊，將各種不同用處的Function作區隔，

因此我大部分的class都依據此規則作function的分類。

#region "region description"

public function fn1() as string

end function

#end region

平常開啟class時候預設的region區塊都是close，必須手動去點選才能展開，

並且只能一個一個展開。

SQL 2005 Database Mail

無法查看此摘要。請 按這裡查看文章。

超機車的病毒

一大早到公司，協理的電腦中毒了，聽說很嚴重，協理便說，系統管理者來了，最後的 希望，如果沒有解就沒救了。
這樣講，要是沒解，招牌就砸了，唉呀，搞了一早，還是沒解，這病毒好機車，不但防止了好多防毒軟體執行，還會自動下載一大堆病毒下來，Vista WinPE開機用ERD command 無法選target系統，執行防毒軟體就顯示【不是正確的Win32應用程式】，解了一個接一個，只能說，協理，你的電腦已百毒纏身了，歐密陀佛。

NTBackup 全自動備份

@Echo Off
ECHO 備份系統狀態中…

REM 設定記錄檔路徑
Set LogFile="D:\Daily\%date:~0,4%%date:~5,2%%date:~8,2%_%time:~0,2%%time:~3,2%%time:~6,2%.TXT"
Set Slp="\\FileServer\SYSTEM\BAK_CMDS_TOOLS\sleep.exe"
SET CDT=建立於 %DATE%%TIME%

REM 備份 DHCP
netsh dhcp server export "\\FileServer\Backup\DHCP\DHCP.TXT" all

REM 4mm DDS 重新整理媒體櫃、實體媒體或特定媒體類型的所有裝置。需等待時間60秒

關於合併頻寬或頻寬負載平衡

這兩天在尋找比較下來，雖然我將相同的問題問了好幾家廠商，但其實是期望有比較好的技術層面的經銷商，其實也說不上技術，只是希望找對產品很熟悉的，才不會一問三不知，遇到問題，找熟悉的人處理，應該比找不熟悉，都找原廠的經銷好吧。

細節的部份，主要是在不影響現有網路架構下，導入此設備，以利增加線路時可使用，同時使用到兩條線路的頻寬。

FiberLogic OptiQroute 2120RS 與 Xtera AscenLink 330比較

價格上實在是落差很多，以功能差別上看來，確是貴的比較少功能，但他究竟貴在哪裡呢？

FiberLogic OptiQroute 2120RS

原廠經提問，如何不改變既有的網路架構與功能，可安裝此設備，並不影響現有網路，且可使用到第二條網路頻寬？

的透通模式 是透過 proxy arp 的方式 搭配 special external route 讓走向相同subnet 線路的 packet 不要再做一次source nat.
可以透過透通模式 ,來達成不改變internet client與 防火牆的public ip 建立VPN封包的ip header

如何在Windows 2008安裝SQL 2000

SQL 2000 能安裝的作業系統最高版本是 Server 2003

而 Server 2008 R2 能安裝的最低 SQL 版本是 2005.

所以在Windows 2008 R2的環境，若直接從 autorun.exe 開始安裝SQL 2000會出現下列錯誤訊息，不論是SQL 2000的哪一個版本都一樣。

直接到光碟路徑下執行 \X86\SETUP\SETUPSQL.EXE ，即可進行安裝。

參考資訊:
http://mydiamond.pixnet.net/blog/post/32291302

Visual Studio 2010 安裝失敗

Visual Studio 2010 用ISO檔案，安裝失敗，停在Microsoft .NET Framework 4 多目標套件。

Microsoft .NET Framework 4 多目標套件，參考個別部署 Visual Studio 2010 元件，無法手動安裝。

解決方式：

更換其他Visual Studio 2010光碟安裝。

SQL 2005 重要效能計數物件(Performance Counter)及建議值

SQL Server - Performance Counter Guidance

Traditionally we have shied away from noting specific values or thresholds that are indicative of good or bad performance. One reason for this is because coming up with good values is quite hard to do, and people sometimes see that a particular value is outside of some threshold and become fixated on that being the issue when in reality it may not be. For example, the Windows NT Resource Kit had a section that stated that a disk queue length greater than two to three times the number of disk spindles was indicative of a performance problem. When working with SQL Server this is not always true, especially if read ahead activity is driving the disk queue length. Just because there is a queue waiting for IO does not necessarily mean that SQL Server is stalled waiting for the IO to complete. We have seen disk queue lengths up in the 20-30 range (on much fewer than 10 disks) where SQL Server performance was just fine.

However, in the absence of specific values people sometimes look at Performance Monitor data and fail to spot interesting trends. So despite the hesitation to provide any specific values, we will attempt to note some thresholds where a given counter starts to attract the interest of those who have been working some of these cases over the past several years. Hopefully this will provide you some guidance in things that stand out. But ultimately, you will need to look for other counters that also seem out of range so that you can start developing a pattern of indicators that point to a particular type of problem.

It should be fairly easy for you to visually identify a counter whose value changed substantially during a problematic time period. Quite often you will find that there are many counters that changed significantly. With a blocking problem, for example, you might see user connections, lock waits and lock wait time all increase while batch requests/sec decreases. If you focused solely on a particular counter (or a few counters) you might come to some very different conclusions about what the problem is, and you could very likely be wrong. Some of the changes in counter values are the cause of the original problem, whereas others are just side affects from that problem.

In the ideal situation, the change in the counters that indicate the cause of the problem should lead the counters showing the affect, but due to the granularity used to capture Performance Monitor data some of these distinctions can be lost. If you collect data once every 15 seconds and the problem was of quick onset, it can be hard to figure out if user connections went up first and then lock timeouts, or vice versa. This is where you have to use other available information, such as other performance counters, the customer’s description of the problem, etc, to form a theory as to what you think may be wrong and then look for other supporting data to prove or disprove your theory.

The most important counters are in blue.

It is recommended to save the counters to a CSV file or a SQL Server database.

The sample rate should be every 15 seconds.

This is the list of the SQL Server counters only. Please also use the Windows Server Performance Counters.

SQL Performance Counters
Object	Counter	Preferred Value	Description
SQLServer:Access Methods	Forwarded Records/sec	< 10 per 100 Batch Requests/Sec	Rows with varchar columns can experience expansion when varchar values are updated with a longer string. In the case where the row cannot fit in the existing page, the row migrates and access to the row will traverse a pointer. This only happens on heaps (tables without clustered indexes). Evaluate clustered index for heap tables. In cases where clustered indexes cannot be used, drop non-clustered indexes, build a clustered index to reorg pages and rows, drop the clustered index, then recreate non-clustered indexes.
SQLServer:Access Methods	Full Scans / sec	(Index Searches/sec)/(Full Scans/sec) > 1000	This counter monitors the number of full scans on base tables or indexes. Values greater than 1 or 2 indicate that we are having table / Index page scans. If we see high CPU then we need to investigate this counter, otherwise if the full scans are on small tables we can ignore this counter. A few of the main causes of high Full Scans/sec are • Missing indexes • Too many rows requested Queries with missing indexes or too many rows requested will have a large number of logical reads and an increased CPU time.
SQLServer:Access Methods	Index Searches/sec	(Index Searches/sec)/(Full Scans/sec) > 1000	Number of index searches. Index searches are used to start range scans, single index record fetches, and to reposition within an index. Index searches are preferable to index and table scans. For OLTP applications, optimize for more index searches and less scans (preferably, 1 full scan for every 1000 index searches). Index and table scans are expensive I/O operations.
SQLServer:Access Methods	Page Splits/sec	< 20 per 100 Batch Requests/Sec	Number of page splits per second that occur as the result of overflowing index pages. Interesting counter that can lead us to our table / index design. This value needs to be low as possible. If you find out that the number of page splits is high, consider increasing the fillfactor of your indexes. An increased fillfactor helps to reduce page splits because there is more room in data pages before it fills up and a page split has to occur. Note that this counter also includes the new page allocations as well and doesn’t necessarily pose a problem. The other place we can confirm the page splits that involve data or index rows moves are the fragmented indexes on page splits.
SQL Server:Buffer Manager	Buffer Cache hit ratio	> 90%	This counter indicates how often SQL Server goes to the buffer, not the hard disk, to get data. The higher this ratio, the less often SQL Server has to go to the hard disk to fetch data, and performance overall is boosted. Unlike many of the other counters available for monitoring SQL Server, this counter averages the Buffer Cache Hit Ratio from the time the last instance of SQL Server was restarted. In other words, this counter is not a real-time measurement, but an average of all the days since SQL Server was last restarted. In OLTP applications, this ratio should exceed 90-95%. If it doesn't, then you need to add more RAM to your server to increase performance. In OLAP applications, the ratio could be much less because of the nature of how OLAP works. In any case, more RAM should increase the performance of SQL Server OLAP activity.
SQL Server:Buffer Manager	Free list stalls/sec	< 2	Free list stalls/sec is the frequency with which requests for available database pages are suspended because no buffers are available. Free list stall rates of 3 or 4 per second indicate too little SQL memory available.
SQL Server:Buffer Manager	Free pages	> 640	Total number of pages on all free lists.
SQL Server:Buffer Manager	Lazy Writes/Sec	< 20	This counter tracks how many times a second that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free up buffer space. Generally speaking, this should not be a high value, say more than 20 per second or so. Ideally, it should be close to zero. If it is zero, this indicates that your SQL Server's buffer cache is plenty big and SQL Server doesn't have to free up dirty pages, instead waiting for this to occur during regular checkpoints. If this value is high, then a need for more memory is indicated.
SQL Server:Buffer Manager	Page Life Expectancy	> 300	This performance monitor counter tells you, on average, how long data pages are staying in the buffer. If this value gets below 300 seconds, this is a potential indication that your SQL Server could use more memory in order to boost performance.
SQLServer:Buffer Manager	Page lookups/sec	(Page lookups/sec) / (Batch Requests/sec) < 100	Number of requests to find a page in the buffer pool. When the ratio of page lookups to batch requests is much greater than 100, this is an indication that while query plans are looking up data in the buffer pool, these plans are inefficient. Identify queries with the highest amount of logical I/O's and tune them.
SQL Server:Buffer Manager	Page reads/sec	< 90	Number of physical database page reads issued. 80 – 90 per second is normal, anything that is above indicates indexing or memory constraint.
SQL Server:Buffer Manager	Page writes/sec	< 90	Number of physical database page writes issued. 80 – 90 per second is normal, anything more we need to check the lazy writer/sec and checkpoint counters, if these counters are also relatively high then, it’s memory constraint.
SQLServer:General Statistics	Logins/sec	< 2	> 2 per second indicates that the application is not correctly using connection pooling.
SQLServer:General Statistics	Logouts/sec	< 2	> 2 per second indicates that the application is not correctly using connection pooling.
SQLServer:General Statistics	User Connections	See Description	The number of users currently connected to the SQL Server. Note: It is recommended to review this counter along with “Batch Requests/Sec”. A surge in “user connections” may result in a surge of “Batch Requests/Sec”. So if there is a disparity (one going up and the other staying flat or going down), then that may be a cause for concern. With a blocking problem, for example, you might see user connections, lock waits and lock wait time all increase while batch requests/sec decreases.
SQL Server:Latches	Latch Waits/sec	(Total Latch Wait Time) / (Latch Waits/Sec) < 10	This is the number of latch requests that could not be granted immediately. In other words, these are the amount of latches, in a one second period that had to wait.
SQL Server:Latches	Total Latch Wait Time (ms)	(Total Latch Wait Time) / (Latch Waits/Sec) < 10	This is the total latch wait time (in milliseconds) for latch requests in the last second
SQL Server:Locks	Lock Wait Time (ms)	See Description”	Total wait time (milliseconds) for locks in the last second. Note: For “Lock Wait Time” it is recommended to look beyond the Avg value. Look for any peaks that are close (or exceeds) to a wait of 60 sec. Though this counter counts how many total milliseconds SQL Server is waiting on locks during the last second, but the counter actually records at the end of locking event. So most probably the peaks represent one huge locking event. If those events exceeds more than 60seconds then they may have extended blocking and could be an issue. In such cases, thoroughly analyze the blocking script output. Some applications are written for timing out after 60 seconds and that’s not acceptable response for those applications.
SQL Server:Locks	Lock Waits/sec	0	This counter reports how many times users waited to acquire a lock over the past second. Note that while you are actually waiting on the lock that this is not reflected in this counter—it gets incremented only when you “wake up” after waiting on the lock. If this value is nonzero then it is an indication that there is at least some level of blocking occurring. If you combine this with the Lock Wait Time counter, you can get some idea of how long the blocking lasted. A zero value for this counter can definitively prove out blocking as a potential cause; a nonzero value will require looking at other information to determine whether it is significant.
SQL Server:Locks	Number of Deadlocks/sec	< 1	The number of lock requests that resulted in a deadlock.
SQLServer:Memory Manager	Total Server Memory(KB)	See Description	The Total Server Memory is the current amount of memory that SQL Server is using. If this counter is still growing the server has not yet reached its steady-state, and it is still trying to populate the cache and get pages loaded into memory. Performance will likely be somewhat slower during this time since more disk I/O is required at this stage. This behavior is normal. Eventually Total Server Memory should approximate Target Server Memory.
SQLServer:SQL Statistics	Batch Requests/Sec	See Description	This counter measures the number of batch requests that SQL Server receives per second, and generally follows in step to how busy your server's CPUs are. Generally speaking, over 1000 batch requests per second indicates a very busy SQL Server, and could mean that if you are not already experiencing a CPU bottleneck, that you may very well soon. Of course, this is a relative number, and the bigger your hardware, the more batch requests per second SQL Server can handle. From a network bottleneck approach, a typical 100Mbs network card is only able to handle about 3000 batch requests per second. If you have a server that is this busy, you may need to have two or more network cards, or go to a 1Gbs network card. Note: Sometimes low batch requests/sec can be misleading. If there were a SQL statements/sec counter, this would be a more accurate measure of the amount of SQL Server activity. For example, an application may call only a few stored procedures yet each stored procedure does lot of work. In that case, we will see a low number for batch requests/sec but each stored procedure (one batch) will execute many SQL statements that drive CPU and other resources. As a result, many counter thresholds based on the number of batch requests/sec will seem to identify issues because the batch requests on such a server are unusually low for the level of activity on the server. We cannot conclude that a SQL Server is not active simply by looking at only batch requests/sec. Rather, you have to do more investigation before deciding there is no load on the server. If the average number of batch requests/sec is below 5 and other counters (such as SQL Server processor utilization) confirm the absence of significant activity, then there is not enough of a load to make any recommendations or identify issues regarding scalability.
SQLServer:SQL Statistics	SQL Compilations/sec	< 10% of the number of Batch Requests/Sec	The number of times per second that SQL Server compilations have occurred. This value needs to be as low as possible. If you see a high value such as over 100, then it’s an indication that there are lots of adhoc queries that are running, might cause CPU usage, solution is to re-write these adhoc as stored procedure or use sp_executeSQL.
SQLServer:SQL Statistics	SQL Re-Compilations/sec	< 10% of the number of SQL Compilations/sec	This needs to be nil in our system as much as possible. A recompile can cause deadlocks and compile locks that are not compatible with any locking type.
Performance Counters for SQL Server 2005 ( SQL Server Premier Field Engineers in Microsoft UK )

SQL Server - Performance Counter Guidance

雲端技術

最進常聽到『雲端』，雜誌訪問林百里談雲端，有聽沒有懂，是網路，還是雲端。

以下內容是擷取自網路新聞:

隨著微軟 (MSFT-US) 執行長史蒂夫．鮑默爾 (Steve Ballmer) 旋風式訪台，雲端技術成為了台灣科技產業近期最火熱的話題。雲端聽起來很有距離感，就像經濟部長形容的「雲深不知處」一樣，很多人都不懂這項技術到底在做什麼，不過，其實人類的生活中，早已處處是「雲端技術」。
到底什麼是雲端技術？Google (GOOG-US) 定義「雲端運算」是一種將日常資訊、工具及程式放到網際網路上的資源利用新方式，正因為所有資訊都被放置到網路的虛擬空間裡，因此稱之為雲端 。使用者可以透過任何連上網的終端裝置，隨時隨地接受郵件、或分享圖文資訊。

這樣的定義，看起來很抽象，不過，舉個生活中顯而易見的例子，例如網路郵件服務、網路相簿等，就是最常出現在我們日常生活週遭的雲端計算 。

所謂「雲端」其實就是泛指「網? 禲v ，名稱來自工程師在繪製示意圖時，常以一朵雲來代表「網路」。因此，「雲端運算」用白話文講就是「網路運算」。 舉凡運用網路溝通多台電腦的運算工作，或是透過網路連線取得由遠端主機提供的服務等，都可以算是一種「「雲端運算」。 所以說，「雲端運算」其實不是新技術，更嚴格的說，甚至不能算是「技術」。「雲端運算」是一種概念 ，代? 磲漪O利用網路使電腦能夠彼此合作或使服務更無遠弗屆。而在實現「概念」的? L程中，才會產生出相應的「技術」。

這就是 雲端技術的奧妙~ 還真有趣 !!

故事是這樣的 :

a phone call ~~ ringing...

客服：「東東披薩店您好！請問有什麼需要我為您服務？」
顧客：「妳好，我想要………」
客服：「先生，請把您的AIC會員卡號碼告訴我。」
顧客：「喔！請等等，12345678。」
客服：「陳先生您好，您是住在泉州街一號二樓，您家電話是23939889，您的公司電話是23113731，您的行動電話是0939956956，請問您現在是用哪一個電話呢？」
顧客：「我家，為什麼妳知道我所有的電話號碼？」
客服：「陳先生，因為我們有連線到『AICCRM系統』。」
顧客：「我想要一個海鮮披薩……」
客服：「陳先生，海鮮披薩不適合您。」
顧客：「為什麼？」
客服：「根據您的醫療紀錄，您有高血壓和膽固醇偏高。」
顧客：「那……妳們有什麼可以推薦的？」
客服：「您可以試試我們的低脂健康披薩。」
顧客：「妳怎麼知道我會喜歡吃這種的？」
客服：「喔！您上星期一在中央圖書館借了一本《低脂健康食譜》。」
顧客：「哎呀！好……我要一個家庭號特大披薩，要多少錢？」
客服：「嗯，這個足夠您一家十口吃，六百九十九元。」
顧客：「可以刷卡嗎？」
客服：「陳先生，對不起，請您付現，因為您的信用卡已經刷爆了，您現在還欠銀行十萬四千八百零七元，而且還不包括房貸利息。」
顧客：「喔！那我先去附近的提款機領錢。」
客服：「陳先生，根據您的記錄，您已經超過今日提款機提款限額。」
顧客：「算了！妳們直接把披薩送來吧，我這裡有現金。妳們多久會送到？」
客服：「大約三十分鐘，如果您不想等，可以自己騎車來。」
顧客：「什麼？！」
客服：「根據『AICCRM系統』記錄，您有一輛摩托車，車號是GY-7878。」
顧客：「……＃@$%^&$%^&※！」
客服：「陳先生，請您說話小心一點。您在八十九年四月一日用髒話侮辱警察，被判了十日拘役。」
顧客：「………………」
客服：「請問還需要什麼嗎 ?」
顧客：「沒有了，是不是有送三罐可樂？」
客服：「是的！不過根據『AICCRM系統』記錄，您有糖尿病…………」

Robocopy

Robocopy， Robust File Copy
可以複製檔案，包含複製旗標、資料、屬性、時間戳記、安全性ACL、擁有者資訊、稽核資訊。
鏡像樹狀目錄
多執行緒複製
失敗重試次數
檔案期限、大小、存取日期上下限

Windows 2008的Robocopy，加參數 /COPYALL ，不等於加了 /SEC，複製完成後未包含ACL資訊。
如果已經複製完成，且未包含權限，可使用AccessEnum掃瞄原本資料夾及其下所有目錄檔案，找出不同權限的目錄檔案，並列出路徑，並可直接點選右鍵選property，參考其安全性設定，以利設定複製出來的檔案目錄權限。

References
Robocopy