Issue:
Unable to connect to Telescope from TheSky6  (ASCOM telescope field blank in 'Telescope API' settings)

This was a showstopping issue that prevented connection to LX200 telescope from TheSky6 and forced the S1022A session to be ended before observations could be made.

Issue occurred previously on 2022-01-17 (S955) although the reason was unknown it was resolved by starting TheSky6 one-time as administator.

Description
Whilst trying to Connect Telescope (ThSky6) during Session S1022A the observatory's LX200 telescope couldn't be connected to TheSy6.   Investigating showed that the 'Telescope API' settings had a blank ASCOM telescope field, instead of the expected "Device Hub Telescope".  Whilst 'Device Hub Telescope' could be choosen in the ASCOM Telescope Chooser,  the value isn't saved when the ASCOm Telescope Chooser is closed, but instead reverts to a blank field if the Settings is reopened. Attempts to resolve issue during session failed. 

Issue has suddenly appeared.  Previous S1021 (2022-07-12) session operated without problem.

Since then an Automatic Windows Update has taken place in daylight hours.

[ Window may have closed/killed a running instance of TheSky6 in order to automatically restart the computer (a totally annoying behaviour by Windows).  InstallShield may also have run & tried an attempt to update TheSky6 in last 2 couple of days.  These are shown to be red-herrings ]

Reinstallation of TeleAPI Plug (5.0.4) didn't resolve the problem.

The following Registry subkey was checked
 HKEY_USERS\...\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\SPACE.com\TheSky TeleAPI-ASCOM Plugin
The Key ASCOM Driver ID had the expected value 'ASCOM.DeviceHub.Telescope' suggesting TheSky6/TeleAPI had a read/write access problem to the necessary area in the registry rather than there being a data issue.

Analysis
Problem is somewhat similar to a previous issue seen on Development Computer but not on the Observatory Computer till now.  

After encountering the problem the TheSky6/Telescope API setting was checked on the AllSky/Weather Computer and a similar issue was noted. Upon selecting and trying to save 'Device Hub Telescope', from ASCOM Telescope Chooser an error dialog appeared  "TheSky TeleAPI ASCOM Plugin.  Failed to create or open the plug-ins registry area".     The error dialog was one that wasn't shown on the Observatory Computer but the behaviour of Telescope API settings was the same.   The AllSky/Weather Computer had likewise been restarted as part of Windows Update earlier on 2022-07-14.

The same issue also affected the Development Computer the following day (2022-07-15) appearing immediately after the computer was restarted following a Windows Update. This confirms that the issue is a direct result of the latest Window Update.

Fix
Issue eventually resolved the following day (2022-07-15) by starting TheSky6 as Administrator.  

Telescope API setting was changed to 'Device Hub Telescope' whilst at administrator level (but this was probably not critical).  TheSky6 was then started normally and Telescope API setting checked to confirm that the underlying issue had been overcome.  Whilst operating TheSky6 with normal user rights it was shown that Telescope API setting could be successfully changed  to 'Telescope Simulator for .Net' and back to  'Device Hub Telescope' again.

The same fix successfully worked also for the AllSky/Weather and Development Computers.  For the Development Computer it was shown that the setting of Telescope API  from 'blank' to  'Device Hub Telescope' didn't have to take place when running as Adminstrator but could be successfully made afterwards when running TheSky6 as a normal user. 

Conclusion
The concurrance of the issue on 3 separate computers at around the same time demonstrate a direct linkage to the latest 2022-07 Windows Update.  

The latest updates on the three affected computers are listed below.

It is likely that the issue has been caused by KB 5015807
  (2022-07 Cumulative Update for Windows 10 Version 21H1 / 21H2 for x64 based Systems (KB 5015807) )
but the possibility that it is due to KB 890830 can't be ruled out
  (Windows Malicious Software Removal Tool - x64 - v5.103 (KB 890830) )

At this stage it is unclear if this is a one-off event or it will be a regular occurance following future Windows updates.

Observatory Computer

• 2022-07 Cumulative Update for Windows 10 Version 21H2 for x64 based Systems (KB 5015807)
  - Successfully installed on 2022-07-13
   
•  Windows Malicious Software Removal Tool - x64 - v5.103 (KB 890830)
  - Successfully installed on 2022-07-13

AllSky/Weather Computer

• 2022-07 Cumulative Update for Windows 10 Version 21H1 for x64 based Systems (KB 5015807)
  - Successfully installed on 2022-07-13
   
•  Windows Malicious Software Removal Tool - x64 - v5.103 (KB 890830)
  - Successfully installed on 2022-07-13

Development Computer

• 2022-07 Cumulative Update for Windows 10 Version 21H1 for x64 based Systems (KB 5015807)
  - Successfully installed on 2022-07-15
   
• 2022-07 .Net Core 3.1.27 Update for x64 Client (KB 5016404)
  - Successfully installed on 2022-07-15
   
• 2022-07 .Net Core 6.0.7 Update for x64 Client (KB 5016405)
  - Successfully installed on 2022-07-15
   
• Windows Malicious Software Removal Tool - x64 - v5.103 (KB 890830)
  - Successfully installed on 2022-07-15

Actions
User: TheSky6/Telescope API setting to be checked directly after restarts of the Observatory Computer following future installation of Windows Updates. At the moment this needs to be remembered by the user.  

CCDSoft5. Following a possible change in the interaction between CCDSoft.Camera and AstroMain's ObsMonitor(Update Foc1 Fields) causing both items to lock-up & not respond,  it was decided to start up CCDSoft5 program as Administrator, just in case it had also suffered as a consequence of the same Windows Update.

Issue:
Unsuccessful rollback of Live Folder to previous session.

Description
'Rollback Live Folder' is a process run from AstroPlans' Settings /Rollback tab to replace files in Live Folder with the files that existed in the folder at the end the previous session, and is used in a situation where a session has been attempted , but failed in someway (software/hardware or weather conditions. The purpose is to allow pictures and files on website's Current/Latest Session web page to go back to showing last successful session, rather than the recent unsuccessful session.

Following S1022A session attempt, an attempt was made directly afterwards in AstroPlan to 'Rollback Live Folder' to the previous S1022 session (2022-07-12) using rollback button on AstroPlan's Settings/Rollback tab but it was unsuccessful.  Files were instead rolled back to files fron earlier S1020 session (2022-06-27).  Item is deemed to be a major issue as files from 2022-07-12 are not retained anywhere preventing a manual rollback of files. 

Analysis
An attempt to rollback files after S1021A session attempt (2022-07-07) was previously unsuccessful  (through manually recoverable) after which changes were introduced on 2022-07-08 in an attempt to resolve the earlier problem
- AstroMain's BackUpLiveFolder() routine was changed in AstroMain 3.52.3 to copy SavedSession () to SavedSession_Previous()  as well as archiving it as a dated folder.  
- AstroPlan's RollBackLiveFolder() changed in AstroPlan 1.30.9 to replace 'SavedSession' folder with a copy of SavedSession_Previous folder prior to rolling back files in LiveFolder.  

Investigating the following day :
- 'Live' folder contains files from S1020 (2022-06-27), but with last modified dates set to 2022-07-14 23:40 (to get around cache/access issues ?), 
- 'SavedSession' folder (created 2022-07-14 23:40) contains files from S1020 (last modified 2022-06-27 & 2022-06-28),  
- 'SavedSession_Previous' and 'SavedSession_20220713_0234 folders (created 2022-07-13 02:34 at end of session S1021) contains files from S1020 (last modified 2022-06-27 & 2022-06-28). 

No backup of live files from S1021 is preserved. 

Reviewing logfile from S1021 session and code from AstroMain 3.52.3 / 3.52.4 indicates that at end of session the prior 'SavedSession' folder (files from S1020) was copied to a new 'SavedSession_Previous' folder and then moved to 'SavedSession_20220713_0234' , before copying 189 files in Live Folder to a new 'SavedSession' folder.  Because the failed S1022A session never proceeded through finishing state, it never called RollBackLiveFolder() to archive SavedSession folder (with S1021 files) as 'SavedSession_Previous'  or as a timestamped archive folder.  

When 'Rollback LiveFolder' was run in AstroPlan the SessionFolder (with S1021 files) was overwritten with the S1020 files in 'SessionFolder _Previous'.

Conclusion
The user needs to be aware of the danger of rolling back files if the last session hadn't proceeded through Finishing State. 

The current RollBackLiveFolder() routine is flawed in that it doesn't backup the files from the Live Folder (or alternatively from the new SavedSession folder) to a timestamped archive folder that would have at least allowed a manual rollback to have been successful. 

Issue could have been mitigated/prevented by a couple of improvements:

It would be helpful if AstroPlan could indicate the date/session no. of the files that are about to be overwritten and the date/session no. of the replacement files

It would be helpful of AstroMain had a button routine to manually call the BackUpLiveFolder() routine.

Actions

AstroMain.  Modify RollBackLiveFolder() routine is flawed in that it doesn't backup the files from the Live Folder (or alternatively from the new SavedSession folder) to a timestamped archive folder. Fixed in AstroMain 3.52.5 (2022-07-15).
 
AstroMain.  Add button routine to manually call the BackUpLiveFolder() routine. Added to AstroMain 3.52.5 (2022-07-15).
 
AstroPlan. Modifiy RollBack Live Folder dialog to indicate the date/session no. of the files that are about to be overwritten and the date/session no. of the replacement files. Modified in AstroPlan 1.30.10 (2022-07-15).

For x64-based systems

1. Click Start, type regedit in the Start Search box, and then click OK.
    
   
2. Locate the following registry subkey:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl
    
   
3. Right-click FeatureControl, point to New, and then click Key.
4. Enter FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, and then press Enter to name the new key.
5. Right-click FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, point to New, and then click DWORD (32-bit) Value.
6. Enter iexplore.exe, and then press Enter to name the new value.
7. Right-click iexplore.exe, and then click Modify.
8. In the Value data box, enter 00000001, and then click OK.
    
   
9. Locate the following subkey:
   HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl
    
   
10. Right-click FeatureControl, point to New, and then click Key.
11. Enter FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, and then press Enter to name the new key.
12. Right-click FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, point to New, and then click DWORD (32-bit) Value.
13. Enter iexplore.exe, and then press Enter to name the new value.
14. Right-click iexplore.exe, and then click Modify.
15. In the Value data box, enter 00000001, and then click OK.
     
    
16. Exit Registry Editor, and then restart the browser to enable the new key.

Note If the value of the iexplore.exe registry entry is 0, or if the registry entry doesn't exist, the notification feature is enabled by default.

Details at https://support.microsoft.com/en-us/topic/the-new-end-of-life-upgrade-notification-for-internet-explorer-ca9a8d93-3f92-ee13-f608-a585f4fa08d4