Replies

Paul T wrote:

If you are making a backup the cache will be exhausted fairly quickly and you will be back to only 300MB. You can test this by copying a multi-GB file using Robocopy – it produces a nice performance summary, but you must use the “NP” option to disable the screen updates until the copy finishes.

I copied a 111GB file to the Acasis Thunderbolt 4 drive using Robocopy. (Actually it was a 111GB folder with that large file and two tiny ones. I had a hard enough time figuring out how to get Robocopy to do *that*, let alone a single file copy.) I used the /NP switch.

Stats: Copy time 1 minute 6 seconds for the 111GB. Speed: 1716.7 MB/s (I just took the number Robocopy gave in bytes and divided by one million.) So if it were a straight-line decline in speed (and I don’t know if that’s a good assumption), the ending speed would have been 732MB/s ([2700+732]/2=1716).

And could the SSD itself have some impact on that? The one I’m using in the Acasis is a to-date unused 4TB Crucial P3 Plus, which is Gen 4 but — according to what I’ve read — uses older technology that subjects it to large drops in transfer speed, especially during long transfers and as the drive fills.

1 user thanked author for this post.

Ed Tittel

I recently did buy the Acasis TBU405 Pro external M2 NVME SSD enclosure, the one with the fan.  It supports Thunderbolt 4, as does my Win 10 laptop (Lenovo Thinkpad P1 Gen 5).

I inserted that Crucial P3 Plus SSD I mentioned and then tested transfer speeds, which I’ve read are typically 2500-3000 MB/s with that setup, for both read and write.  Well, I got about 3000 MB/s read but only 300 MB/s write.  While that write speed was FAR better than I had been getting with USB 3, it was nowhere near 2500-3000.

Then I read a review that says Windows 10 and 11 disable write caching on external drives by default.  I checked the properties for the Acasis, and sure enough that was the case.  So I ticked the box to enable write caching, and boom, now I am getting about 2700 MB/s writes.  Absolutely blazing.

But that leads to my question:  Is it unwise to enable write caching, especially on a drive that will be used primarily for creating system drive images and other backups?  As you know, Windows has that disclaimer that with write caching enabled, a power outage or equipment failure might result in data loss or corruption.  And I don’t have an uninterruptible power supply.

I further wonder, in the event data loss or corruption does result, is it likely to be confined to the data I was attempting to transfer at the time?  That wouldn’t be so bad, because what I’m transferring is typically an image or a copy, i.e. redundant to what’s still on the source drive.  Or could it also cause issues with other data that’s already on the external drive — which would be much worse?

CORRECTION #2, again re dotNET 4.8:   As with the SMQR, the update used is for Server 2008 R2 x64.  This and the last correction were probably obvious, but I didn’t want to leave even a little doubt.

BTW, I haven’t noticed any issues since the updates, although I don’t use that computer much.

 

CORRECTION:  The dotNET 4.8 Quality Rollup was installed using the latest version of the dotNetFx4 installer

 

Summarizing what I wrote in bits and pieces above, here is how I proceeded with the Win 7 updates (on a less-frequently-used machine, for test purposes) :

1. Installed 2025-01 Servicing Stack 2025-01 Servicing Stack KB5050681 a few days ago, using installer v.4 W7ESUI_0_4.  Then, today:
2. Downloaded (without any interventions) and installed 2025-01 Rollup KB5050049 (for Server 2008 R2 x64), using v.4 W7ESUI_0_4.  Restarted.
3. Downloaded and installed 2025-01 dotNET 4.8 Quality Rollup KB5049619 (for Windows Embedded 7), using W7ESUI.  Restarted. (Initial failures turned out to be caused by interventions by my new AV, now solved.)
4. Ran MSRT via Windows Update.

3 users thanked author for this post.

SteveIT, Pim, abbodi86

Yep, it looks like there were “just” some convoluted issues I had to work through with the new AV.  After that, the dotNET 4.8 Quality Rollup KB5049619 for Win 7 embedded installed fine as well.

While the Win 7 SMQR went fine, the dotNET 4.8 Quality Rollup KB5049619 install failed in minutes with code 1603.  I tried several times, including re-downloading it.  Unless I later see reports of it being installed OK (thus suggesting there’s been a fix) I’m inclined to just skip it this month as a lower priority than the Win 7 SMQR.

Instead of doing a separate summary post, I’ll just add here that I already did the SSU update a few days ago.

EDIT:  It looks like I might not have the latest version of the dotNET installer on that infrequently-used machine.  I’m going to retry shorty ensuring I have the latest version of the installer.

EDIT2:  Before the edit window closes, I want to add that it looks like the issue installing the dotNET update may be due to a new free antivirus added to this machine.

 

Well, in any event I just tested, and the Win 7 SMQR (using Server 2008 R2 x64 updates) KB5050049 downloaded and installed OK with no modification required.  So either MS has fixed it, or the problem only applies to 8.1 (using Server 2012 R2 x64 updates).  Will provide more detail after I do the dotNET 4.8 update.

 

2 users thanked author for this post.

SteveIT, George1

Could you post a shot of where it says, “Update ID”?  Like @EricB, I see nothing to that effect.  Is it possible that the dialog in Win 8.1 is slightly different that in Win 7?  Or that clicking the Copy button has no effect in Win 7 (at least for these updates)?  When you found something referring to the issue for these updates, was it specifically about Win 8.1, or was Win 7 referenced?

While I would normally wait until Susan’s MS-Defcon 3, later today I’ll give the Win 7 SMQR a try on a computer I don’t use very often, and report back.

I thought I followed the instructions word for word.  I tried a couple times.

It’s likely I’m missing something obvious here (especially since I’m unfamiliar with the world of digital signatures), but I’m not sure what you’re referring to now by “at the top under ‘Check’ and the at the bottom under the original.”

For SMQR KB5050049 in Win 7, the SHA value remains unchanged at SHA1 after I click Copy.  Do we know that the same issue you encountered in Win 8 necessarily exists for Win 7 (using Server 2008 R2 x64 updates) this month?

Whether I download KB5050049 with or without clicking Copy first, I note that the resulting download says SHA256 in the Digital Signatures tab of File Properties.

 

1 user thanked author for this post.

SteveIT

Glancing at the notes I made at the time, to get Outlook 2003 to use TLS 1.2, I not only had to run the Easy Fix, but also make a few additional registry and Internet Options mods to ensure TLS 1.2 became not just enabled in Win7, but also the default secure protocol in WinHTTP.

On the computer in question I use web-based email.  While I can appreciate the positives of other OS’s, I’ll probably stick with Windows.  Thanks for the suggestions.

Thanks for the suggestion, but that’s more than the computer’s worth!  I use it mostly for surfing, email, etc.  So maybe it’s just time to buy a relatively low-priced recent-vintage laptop.  Or maybe I can just update this Dell to Win10.

I’m still connecting using Outlook 2003 (not a typo).   All POP3.  I have Yahoo and Comcast accounts.  (I also have Gmail accounts, but have never accessed those on Outlook).

The Yahoo accounts play fine with OL 2003; I just have to use an “app password” for each account that’s easily generated at Yahoo.  Comcast still uses its regular login credentials, but a year ago they added a requirement that connections be via the newer TLSv1.2 security.  I thought there was little chance of getting Outlook 2003 in Win 7 to do that, but with some “deep Googling” and trial-and-error I somehow was able to make it happen.

1 user thanked author for this post.

SueW