Date   

Re: How to prevent automated updates on Windows 10 Home

Barry Smith
 

In message <11375.1534779534243984527@groups.io>
"Thorsten Miglus" <thorsten.miglus@...> wrote:

Hi Barry,
you can go to the Task Scheduler.
Microsoft->Windows->UpdateOrchestrator
Then run the task "Schedule Scan" manually by right click.
If the result is "permission denied", automated updates are blocked
successful.
Cheers,
Thorsten
I'm NOT getting "permission denied".

Looking at Advanced Security Settings for UsoClient, if I change both
ALL and ALL RESTRICTED from Read & execute to just Read, it may cause
other problems and I don't want that to happen.

I may try the instructions (from the web page) again tomorrow and see
if it works.

Barry
--


Re: How to prevent automated updates on Windows 10 Home

Barry Smith
 

In message <7DCD6C561F934F4EB2775EAD847502D7@Alta>
"David J Taylor via Groups.Io"
<gm8arv=yahoo.co.uk@groups.io> wrote:

I would strongly recommend anyone using a computer interactively (Web
browsing, e-mail, Twitter etc.) /not/ to turn off Windows updates
permanently. Servers running 24 x 7 with no user interaction are, of
course, a different issue.
If you follow Thorsten's suggestion, please do remember to run updates at
least one a month.
I know that updates are issued monthly - I think the 2nd Tuesday of
each month - I just want to be "available" when it is doing the
update, not come to the computer and find it has performed the update
without my "permission".

I'm aware of the "active hours" settings, but that doesn't stop the
update if there is no mouse/keyboard activity.

Barry
--


Re: How to prevent automated updates on Windows 10 Home

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

I would strongly recommend anyone using a computer interactively (Web browsing, e-mail, Twitter etc.) /not/ to turn off Windows updates permanently. Servers running 24 x 7 with no user interaction are, of course, a different issue.

If you follow Thorsten's suggestion, please do remember to run updates at least one a month.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: How to prevent automated updates on Windows 10 Home

Thorsten Miglus
 

Hi Barry,

you can go to the Task Scheduler.
Microsoft->Windows->UpdateOrchestrator
Then run the task "Schedule Scan" manually by right click.
If the result is "permission denied", automated updates are blocked successful.

Cheers,
Thorsten


On Mon, Aug 20, 2018 at 04:19 PM, Barry Smith wrote:
In message <4393.1534761046113728981@groups.io>
"Thorsten Miglus" <thorsten.miglus@...> wrote:

Hi Barry,
please run cmd (command line) as Administrator, not the PowerShell.
Cheers,
Thorsten
Thanks. That was hard work!

It's not clear from the website (link you gave) what I should see at
the very end.

I right clicked on UsoClient.exe, Properties, Security, Advanced,
Permissions (Continue).

There are 3 entries
Trusted Installer - Full Control
All application packages - Read & execute
All restricted application packages - Read & execute.

Is that correct? It doesn't seem to be any different from the PC I
have NOT modified.

Do I need to change the Access to Read (only) instead of Read&execute?

Barry


Re: How to prevent automated updates on Windows 10 Home

Barry Smith
 

In message <4393.1534761046113728981@groups.io>
"Thorsten Miglus" <thorsten.miglus@...> wrote:

Hi Barry,
please run cmd (command line) as Administrator, not the PowerShell.
Cheers,
Thorsten
Thanks. That was hard work!

It's not clear from the website (link you gave) what I should see at
the very end.

I right clicked on UsoClient.exe, Properties, Security, Advanced,
Permissions (Continue).

There are 3 entries
Trusted Installer - Full Control
All application packages - Read & execute
All restricted application packages - Read & execute.

Is that correct? It doesn't seem to be any different from the PC I
have NOT modified.

Do I need to change the Access to Read (only) instead of Read&execute?

Barry
--


Re: How to prevent automated updates on Windows 10 Home

Thorsten Miglus
 

Hi Barry,

please run cmd (command line) as Administrator, not the PowerShell.

Cheers,
Thorsten


On Sun, Aug 19, 2018 at 11:38 PM, Barry Smith wrote:
In message <7559.1534273568566766047@groups.io>
"Thorsten Miglus" <thorsten.miglus@...> wrote:

Hi all,
I am testing a new method to prevent automated updates on Windows 10.
This method works with Win 10 version 1709 and up.
I'd like to try this on one of my PCs. I have 2 and both are Windows
10 Pro version 1803.

C:\Windows\System32\UsoClient.exe is executed for automated updates.
Removing all permissions from UsoClient.exe prevents automated updates
to start.
But you can still run update scans manually by opening Settings >
Update & Security.
How to do this:
1. Run the command line as admistrator.
Is this the same as Administrator: Windows PowerShell ?

or should I use Run Open cmd ?

2. Take over ownership of UsoClient.exe:
takeown /f ”%WINDIR%\System32\UsoClient.exe• /a
3. Remove permissions:
*icacls ”%WINDIR%\System32\UsoClient.exe• /inheritance:r /remove
”Administrators• ”Authenticated Users• ”Users• ”System•
* Note that you may need to change the English group names if you use
a non-English edition of Windows.
To undo the changes enter:
*icacls "%WINDIR%\System32\UsoClient.exe" /reset*
Source: https://info.greatis.com/guide/disable/allow-manual-updates/
Cheers,
Thorsten *
*
Thanks
Barry


Re: How to prevent automated updates on Windows 10 Home

Barry Smith
 

In message <7559.1534273568566766047@groups.io>
"Thorsten Miglus" <thorsten.miglus@...> wrote:

Hi all,
I am testing a new method to prevent automated updates on Windows 10.
This method works with Win 10 version 1709 and up.
I'd like to try this on one of my PCs. I have 2 and both are Windows
10 Pro version 1803.

C:\Windows\System32\UsoClient.exe is executed for automated updates.
Removing all permissions from UsoClient.exe prevents automated updates
to start.
But you can still run update scans manually by opening Settings >
Update & Security.
How to do this:
1. Run the command line as admistrator.
Is this the same as Administrator: Windows PowerShell ?

or should I use Run Open cmd ?

2. Take over ownership of UsoClient.exe:
takeown /f ”%WINDIR%\System32\UsoClient.exe• /a
3. Remove permissions:
*icacls ”%WINDIR%\System32\UsoClient.exe• /inheritance:r /remove
”Administrators• ”Authenticated Users• ”Users• ”System•
* Note that you may need to change the English group names if you use
a non-English edition of Windows.
To undo the changes enter:
*icacls "%WINDIR%\System32\UsoClient.exe" /reset*
Source: https://info.greatis.com/guide/disable/allow-manual-updates/
Cheers,
Thorsten *
*
Thanks
Barry
--


Remainder: Sentinel 3A data will stop on TP1

Thorsten Miglus
 

Hi All,

From "Weekly Operations Schedule":

EUMETCast Satellite data flows on Transponder 1 (TP1) and Transponder 2 (TP2) are being reorganised.
Sentinel-3A data, currently disseminated on TP1, will be transferred to TP2.
From 18/06/2018 to 21/08/2018, they will be available on both TP1 and TP2.
From 22/08/2018, they will only be available on TP2.
For full details on what users need to do to prepare for this change, see the URL provided below.

https://www.eumetsat.int/website/home/News/DAT_3942692.html

Cheers,
Thorsten


How to prevent automated updates on Windows 10 Home

Thorsten Miglus
 

Hi all,

I am testing a new method to prevent automated updates on Windows 10.
This method works with Win 10 version 1709 and up.

C:\Windows\System32\UsoClient.exe is executed for automated updates.
Removing all permissions from UsoClient.exe prevents automated updates to start.
But you can still run update scans manually by opening Settings > Update & Security.

How to do this:
1. Run the command line as admistrator.
2. Take over ownership of UsoClient.exe:
takeown /f “%WINDIR%\System32\UsoClient.exe” /a
3. Remove permissions:
icacls “%WINDIR%\System32\UsoClient.exe” /inheritance:r /remove “Administrators” “Authenticated Users” “Users” “System”
Note that you may need to change the English group names if you use a non-English edition of Windows.

To undo the changes enter:
icacls "%WINDIR%\System32\UsoClient.exe" /reset

Source: https://info.greatis.com/guide/disable/allow-manual-updates/

Cheers,
Thorsten


Re: RSS

Ferdinand Valk
 

-----Original Message-----
From: MSG-1@groups.io <MSG-1@groups.io> On Behalf Of David J Taylor via
Groups.Io
Sent: Sunday, 12 August, 2018 09:32
To: MSG-1@groups.io
Subject: Re: [MSG-1] RSS

I do take the RSS met products. The current coverage is smaller than it will be.
In East-West direction there are no changes; the north-south coverage will be
extended to 22 degrees N. As I understand it this also applies to the basic 11
RSS channels themselves. I'm not sure if the HRV channel will be affected or not.

Ferdinand
===========================

I did the sums (briefly) and the new products fit within the present RSS scan.
Perhaps someone would like to confirm this?

Cheers,
David
--
===============================
You are right David. The current extent of RSS is about16-17degrees north (f) and your cropped nf version stops at 22N. This changes when MSG-2 is used for RSS though (different remap). So, in both cases the extended coverage of MPEF fits within the RSS as-is.

Cheers,
Ferdinand


Re: RSS

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

I do take the RSS met products. The current coverage is smaller than it will be. In East-West direction there are no changes; the north-south coverage will be extended to 22 degrees N. As I understand it this also applies to the basic 11 RSS channels themselves. I'm not sure if the HRV channel will be affected or not.

Ferdinand
===========================

I did the sums (briefly) and the new products fit within the present RSS scan. Perhaps someone would like to confirm this?

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: RSS

Ferdinand Valk
 

-----Original Message-----
From: MSG-1@groups.io <MSG-1@groups.io> On Behalf Of Douglas Deans via
Groups.Io
Sent: Saturday, 11 August, 2018 16:37
To: MSG-1@groups.io
Subject: Re: [MSG-1] RSS

On 11/08/2018 15:00, David J Taylor via Groups.Io wrote:
Yes you are right David, it is only affecting the meteorological
products ( with one exception.) I should have read it more carefully
the first time.

Regards
Ian.
============================
Glad you read it that way too, Ian! For one moment I thought they
might have found a way of squeezing more segments into the 5 minutes,
or changing the interval to 7 minutes, or something else which would
have required massive amounts or reprogramming! Fortunately, not!

Cheers,
David
=========================================================
I don't read it that way. The heading and the first paragraph in the news item
seems to imply it is the RSS and then they explain what meteorological
products will also be affected. It is certainly not very clear.
If your assumption is correct I can only assume that the current meteorological
products do not cover the area provided by the existing RSS scan. I haven't
taken them for a while so I have forgotten.
If they cover the RSS scan as currently provided how can they extend their
products without getting extended raw data ?

Regards,
Douglas.
==================================

I do take the RSS met products. The current coverage is smaller than it will be. In East-West direction there are no changes; the north-south coverage will be extended to 22 degrees N. As I understand it this also applies to the basic 11 RSS channels themselves. I'm not sure if the HRV channel will be affected or not.

Ferdinand


Re: RSS

Douglas Deans
 

On 11/08/2018 15:00, David J Taylor via Groups.Io wrote:
Yes you are right David, it is only affecting  the meteorological
products ( with one exception.) I should have read it more carefully the
first time.
Regards
Ian.
============================
Glad you read it that way too, Ian!  For one moment I thought they might have found a way of squeezing more segments into the 5 minutes, or changing the interval to 7 minutes, or something else which would have required massive amounts or reprogramming!  Fortunately, not!
Cheers,
David
=============================================================================

I don't read it that way. The heading and the first paragraph in the news item seems to imply it is the RSS and then they explain what meteorological products will also be affected. It is certainly not very clear.
If your assumption is correct I can only assume that the current meteorological products do not cover the area provided by the existing RSS scan. I haven't taken them for a while so I have forgotten.
If they cover the RSS scan as currently provided how can they extend their products without getting extended raw data ?

Regards,
Douglas.


Re: Tellicast client version 2.14.4 for Linux

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David,

This is my "understanding" so far:

When TELLICast connects to a channel it opens a socket.
Part of this system call is the size of a (net-) buffer
to be provided by the kernel. The kernel has some max
size limits for read and write buffers. It seems that
the Linux default limits are not enough for TELLICast.
In /etc/sysctl.conf a lot of different kernel defaults
can be adapted. For TC 2.14.1 EUMETSAT asked to set
maximum network buffer sizes to 5500000 Bytes. Maybe
this was a hard coded size TC 2.14.1 was asking for.
Or maybe EUMETSAT just found the clients default of
4000000 (according to TD-15) and added some slack.

Now it seems that the new TC 2.14.4 asks for 4000000 by
default but has the possibility to increase (or lower)
that with "receive_buffer_size" on a TC channel basis.
EUMETSAT now recommends receive_buffer_size=8000000
which means that the max limits in /etc/sysctl.conf
must (at least) be that size. Of course this does not
answer the question of optimum sizes per channel.

As I still had 5500000 as max limit but was asking
for 8000000 the TC client when opening the socket
got a return value that only a 5500000 Bytes buffer
size could be allocated. This was the reason for
the warning in the TELLICast clients log file.

Cheers,
Ernst
============================

Thanks, Ernst. I've not needed to specify a buffer size when writing network code under Windows, but that might simply mean that there is a default buffer size which has been adequate for my needs. I'd been wondering whether this was allocated from a finite pool (e.g. non-pageable memory), but I don't know. Anyway, "If it works, leave it!" is one of my unwritten rules of network programming.

From what you say, it seems that providing you don't set a value of "0", you'll get a warning if the requested buffer can't be allocated, and the program will try to continue with the maximum buffer it could get. Yes, there are buffer size options when opening a Windows socket. On Windows it seems that (at least one) buffer size may be set by the network adapter itself - possibly configurable.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: RSS

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Yes you are right David, it is only affecting the meteorological
products ( with one exception.) I should have read it more carefully the
first time.

Regards
Ian.
============================

Glad you read it that way too, Ian! For one moment I thought they might have found a way of squeezing more segments into the 5 minutes, or changing the interval to 7 minutes, or something else which would have required massive amounts or reprogramming! Fortunately, not!

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: Tellicast client version 2.14.4 for Linux

Ernst Lobsiger
 

David,

This is my "understanding" so far:

When TELLICast connects to a channel it opens a socket.
Part of this system call is the size of a (net-) buffer
to be provided by the kernel. The kernel has some max
size limits for read and write buffers. It seems that
the Linux default limits are not enough for TELLICast.
In /etc/sysctl.conf a lot of different kernel defaults
can be adapted. For TC 2.14.1 EUMETSAT asked to set
maximum network buffer sizes to 5500000 Bytes. Maybe
this was a hard coded size TC 2.14.1 was asking for.
Or maybe EUMETSAT just found the clients default of
4000000 (according to TD-15) and added some slack.

Now it seems that the new TC 2.14.4 asks for 4000000 by
default but has the possibility to increase (or lower)
that with "receive_buffer_size" on a TC channel basis.
EUMETSAT now recommends receive_buffer_size=8000000
which means that the max limits in /etc/sysctl.conf
must (at least) be that size. Of course this does not
answer the question of optimum sizes per channel.

As I still had 5500000 as max limit but was asking
for 8000000 the TC client when opening the socket
got a return value that only a 5500000 Bytes buffer
size could be allocated. This was the reason for
the warning in the TELLICast clients log file.


Cheers,
Ernst

 


Re: RSS

Ian Deans
 

On 11/08/2018 10:11, David J Taylor via Groups.Io wrote:
I see from the Weekly Operations Schedule that there is to be an
extension of the RSS processing area from the 29/8/2018.
Unfortunately the URL they give for details and sample files does not
appear to exist !!
Regards
Ian.
=============================
Ian,
My reading of the announcement is that it only affects certain derived products, and not the basic RSS scan region itself.  Agreed?
Cheers,
David
==========================================================================

Yes you are right David, it is only affecting the meteorological products ( with one exception.) I should have read it more carefully the first time.

Regards
Ian.


Re: RSS

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

I see from the Weekly Operations Schedule that there is to be an
extension of the RSS processing area from the 29/8/2018.

Unfortunately the URL they give for details and sample files does not
appear to exist !!

Regards
Ian.
=============================

Ian,

My reading of the announcement is that it only affects certain derived products, and not the basic RSS scan region itself. Agreed?

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: Tellicast client version 2.14.4 for Linux

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David,

Thanks for the hint with a new version of TD-15 I haven't read before.
Unfortunately the 550000 didn't ring the bell but that's what stands
in /etc/syctl.conf configuring the kernel buffer at startup so far.

The relevant text in TD-15 is:
"
receive_buffer_size=8000000
Defines the kernel receive buffer size for this multicast channel in bytes. The default
value is 4000000. Increasing the buffer helps avoiding losses if the client is
temporarily blocked in IO operation and cannot read the incoming multicast fast
enough, e.g. in case of heavy disk load. On Linux system the following system
parameters in /etc/syctl.conf must be set to the same or higher values:
net.core.rmem_max=8000000 (reboot the system after a change)
"

As I just copied the new client and adapted my cast-channels.ini files
the 550000 limit in /etc/sysctl.conf was left untouched. For the moment
there is only a *.rpm but no *.deb of the new client distributed for an
automatic installation under Debian (or Devuan that I use now). So I
adapted /etc/sysctl.conf setting read and wtite buffers to 8000000 and
rebooted/restarted with receive_buffer_size=8000000 for every channel.

Now the system accepts receive_buffer_size=8000000 without complaining.
So I can make now a more meaningfull test of TC 2.14.4 versus TC 2.24.1.


Cheers,
Ernst
=====================================

Ernst,

Glad that's no working OK.

I had already wondered whether there were similar limits on Windows - the amount of non-paged memory etc. - but these are normally set appropriately by the OS defaults, and use intervention isn't required. I do monitor the memory used by TelliCast, but it didn't seem to change much with the new version. Possibly if that buffer memory is from non-paged pool my usage monitor wouldn't detect that. Quite possibly the first you would know about it would be a crash with something like "insufficient [type of] memory available".

I still don't have a good feeling for what an appropriate value might be - whether it should be different for HVS and BS, for example, or for different channels with different data rates.

I look forward to your results!

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: Tellicast client version 2.14.4 for Linux

Ernst Lobsiger
 

David,

Thanks for the hint with a new version of TD-15 I haven't read before.
Unfortunately the 550000 didn't ring the bell but that's what stands
in /etc/syctl.conf configuring the kernel buffer at startup so far.

The relevant text in TD-15 is:
"
receive_buffer_size=8000000
Defines the kernel receive buffer size for this multicast channel in bytes. The default
value is 4000000. Increasing the buffer helps avoiding losses if the client is
temporarily blocked in IO operation and cannot read the incoming multicast fast
enough, e.g. in case of heavy disk load. On Linux system the following system
parameters in /etc/syctl.conf must be set to the same or higher values:
net.core.rmem_max=8000000 (reboot the system after a change)
"

As I just copied the new client and adapted my cast-channels.ini files
the 550000 limit in /etc/sysctl.conf was left untouched. For the moment
there is only a *.rpm but no *.deb of the new client distributed for an
automatic installation under Debian (or Devuan that I use now). So I
adapted /etc/sysctl.conf setting read and wtite buffers to 8000000 and
rebooted/restarted with receive_buffer_size=8000000 for every channel.

Now the system accepts receive_buffer_size=8000000 without complaining.
So I can make now a more meaningfull test of TC 2.14.4 versus TC 2.24.1.


Cheers,
Ernst