After initial Server "unplanned" Shutdown (BSOD/Crash, hang or power failure), Windows creates Registry flags which are used to prompt the User/Users after a reboot for reason of unplanned reboot.

In a normal situation, after the User acknowledges the prompt, those Registry flags are removed/reset.
In many situations the Registry flags are not removed/reset even after acknowledging the prompt which leads Windows to perpetually prompt after every clean reboot.
Some say that that recent Security Updates are to blame and some with a focus on .NET.

The actual cause is insufficient Permissions on the Registry keys that are flagged - only Local Administrator has the Permission to successfully acknowledge the Prompt to clear the Registry flags.

You need to provide the correct Permissions to the Registry Key: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability
In this case, we have given Domain Administrator's Full Control of this Key (not just Local Administrator). As this Server is also an RDS (Terminal) Server, we have given Domain Users Full Control too but that is your personal choice and may not be desirable if only you, the Domain Administrator, want to acknowledge/see this Prompt.

   

To manually clear the Registry Flags remove (delete) the Registry Values DirtyShutdown, LastAliveStamp, TimeStampInterval under the above Registry Key (or reboot the Server and acknowledge the Prompt again)

The native Windows Ping command can't record timestamps in the results without a lot of fussing around.
Use PowerShell and bang-out the following command to get timestamps on the ping results (replace COMPUTERNAME with either the Host Name or IP Address).

ping.exe -t COMPUTERNAME|Foreach{"{0} - {1}" -f (Get-Date),$_}

To send your results to a text file, pipe the results by appending the following.

ping.exe -t COMPUTERNAME|Foreach{"{0} - {1}" -f (Get-Date),$_}>c:\temp\pingresults.txt

Full Error Message when backing up Exchange with GRT enabled:

V-79-57344-862 - Backup Exec Agent for Exchange not used for last full backup of this database.  You must use the Exchange Agent to run a full backup before you run a differential or incremental backup.

Completed status: Failed
Final error: 0xe000035e - The Backup Exec Agent for Microsoft Exchange was not used to create the last full backup of this database.  You must use the Exchange Agent to run a full backup before you run a differential or incremental backup.
Final error category: Resource Errors

For additional information regarding this error refer to link V-79-57344-862

I have seen this on all Versions of Backup Exec when using Incremental backups on Hyper-V and other Data using separate Backup Jobs.
Although, indeed, other types of Backups will cause this (Windows Backup or other Backups performed by other Software).
Full Backup Jobs are not affected by this error.

Incremental Backups rely on the Attribute set on a file to determine if it has been backed up since modified/created. These Attributes are then flagged (unflagged) during the Backup process. If other Backups of the same Data are run prior to your Backup Exec Job then Backup Exec will get confused and throw this error. 

For us, we run separate Incremental Backup Jobs for Hyper-V and Data.
Turns out that, if we first run the Hyper-V Job then the Data Job, the Backup will fail with this error on the Data Backup.
If we first run the Data Job and then the Hyper-V Job then the Backups "usually" go through without this error.
Backup Exec somehow "thinks" that the previous Hyper-V Backup Job was to blame - not sure how but we have been able to reproduce it.
The problem still lays with the next Incremental Backup (second Incremental Backup after the Full Backup) - some sites, using different Windows Server and Hardware Versions, have unpredictable results - some work flawlessly and others throw these errors.

At some sites where there is ample storage available on the destination media and time-slot available, we do Full Backups instead of Incremental and lengthen the retention period.

If you're backing up Hyper-V with Server 2016/2019 you will notice additional files created with extensions of MRT and RCT.
These files are created by new features of Hyper-V introduced in Server 2016/2019 called "Resilient Change Tracking".

   

The "Resilient Change Tracking" feature is manipulated during the backup of Virtual Machines in which these additional files can aid in recovery of VMs - personally, I don't understand the mechanics involved so I will leave that research up to you.

While not every environment is a clustered one, there have been questions relating to the simple copying of VMs from one Hyper-V Host to another while these files are present.
In our test lab we found that Data was consistent when copying with or without these MRT or RCT Files present.
We found that, if the MRT and RCT Files were copied alongside the VHDX File, the files would become realised and active (not orphaned) and life continued as usual.
If we didn't  copy the MRT or RCT Files there was no Data loss and life continued as usual.

So, if you are here looking for reasoning over what effect these files have on Data integrity during a move/copy, rest assured that there is no Data Loss if you are accustomed to manually copying Virtual Machine Files from one host to another.

This CCTV system is a step above the cheap Chinese ones that I have been using over the past 15-years. Cost has always been a factor in my decisions (isn’t that the same with everyone?).

The initial installation did not go as planned.
Initial setup was positive as we used 0.5M Network Patch Cables to each Camera to test before replacing existing Cameras.
It was a simple plan: to remove the existing PoE Cameras and DVR and replace them with the Reolink Cameras and DVR.
This plan soon turned to custard after days of trying to figure out why none of the 6 Cameras would connect but the old ones would continue to work OK.
It turned out that these new Reolink Cameras demand CAT6 Cabling – all would work OK with CAT5 as long as the cable runs were not longer than 5M.

So, mission accomplished; replaced all CAT5 cabling with CAT6 (400M in total) and all Cameras working as expected.

I’ve been running CCT since day zero but always limited to the cost-factor and ending up with cheap Chinee crap – forever upgrading hoping that things would get better but never did.

I had two simple demands.
1) be able to identify number plates and
2) provide Video evidence to the police without stuffing around.
My biggest peeve was always having to apologise to the Police that it took so long to firstly download the footage and then convert the Video from some weird and bizarre CRAP Video Format to something they could actually use without losing quality.
The Reolink system “partially” solved these issues as I will explain here:
Downloading Video footage directly to MP4 file format is a saviour (no more of that crap H264 to deal with)!
No more having to dick-around with third-party programs to convert while loosing quality.
The downloading of Video takes a long time and not what I expected from a brand with high score marks but still quicker than having to dick-around by converting H264 crap afterwards.
The Video Quality (compared to my previous 1024--resolution HD H264) is not that amazing and I was disappointed in that number plates were still not decipherable when they should be.

What pissed me off was:
1) Reolink 5Mp Cameras came on to the market (Amazon) two weeks after I received my 2Mp Cameras AT THE SAME PRICE!
2) That the Reolink Cameras you purchase are dedicated to their own DVR – meaning you cant use the Reolink Cameras on a non-Reolink DVR – or even use Reolink 4Mp Cameras on a Reolink 2Mp DVR!
3) The CPU usage is mostly maxed out (using 6 of the 8 supported cameras) - seriously underpowered CPU.
4) Response at switching quickly to the Software (Reolink Client) to check on something is sluggish and if left for more than 30-minutes or so shows all feeds as blank (white) screens until one is double-clicked to bring into the foreground. I suppose this would not affect some users who have the Software open all the time on a dedicated monitor but, for me, by the time you have messed around you have missed the live action.

Edit: Tried downloading footage today for an incident. The Software (Reolink Client) kept crashing after the first few video clips. It took multiple attempts to download one or two clips at a time.

Still experiencing...

Try as you may, you are probably here because, no matter what you do, you cannot turn off the Screen Lock of Windows 10 or it annoyingly logs you out after a time-out period (even though you have disabled all of what you could through Power settings).

Apply this Registry Patch to fix the problem.


  ScreenTimeout.reg (Size: 5.87 KB / Downloads: 227)

BackupExec Console Crashes when trying to open it:

   
 
Turns out that .NET Framework 4.8 is the culprit – in particular the security update for it.

Remove one of the following Updates to resolve the issue:
Windows Server 2012 R2 - KB4486105
Windows Server 2012 - KB4486081
Windows Server 2016 - KB4486129
Windows Server 2019 - KB4486153

I suspect that future Versions and Updates to .NET Framework will also result in a broken Backup Exec Console so keep this in mind.

i have problem when running software from mapping drive  got external exception C000006 its happed randomly 

How to setup Linkus with DrayTek Routers.

1) Create Port Redirection Rules as follows:
- Public Port UDP 9850 to Private Port 8111 and to the IP of the PBX
- Public Port UDP 6023 to Private Port 5060 and to the IP of the PBX

   

2) Create an Open Port Rule
- UDP Start 40000 - End 42000 to Private IP of PBX
- UDP Start 10000 - End 12000 to Private IP of PBX

   

3) If you haven't already, install the Linkus App on the PBX and configure it for the Ports you defined above like this:

   

4) On the PBX, go to Settings, General, SIP then NAT and configure the settings as follows:

   

5) Enable the required Extensions for Linkus and click on "Send Email" to send a link to the Users to install the App.

   

Some Yeastar FAQs and Documentation suggest enabling the PBX Firewall which is always a good idea.
However, we have encountered no-audio issues at some multi-site locations which we never figured out when the Firewall was enabled.
At these sites it's always important to ensure your perimeter Router/Firewall is hardened and that your UDP Port 5060 is exposed only to your SIP/VOIP Provider's IP.

Emails previously sent months ago are sent again.
Affected site uses Exchange 2007 (SBS 2008) and Outlook 2007 and Outlook 2010.
This has been randomly going on for years and we never really found a solution out there.

Narrowing it down to the Computer (Email Account) responsible was easy and we further investigated the issue.

Looking in the Outlook Folder C:\Users\Username\AppData\Local\Microsoft\Outlook we found a bunch of Temp Files (0K in size) corresponding to the same amount of sent Emails.
These files begin with "BIT" with some examples shown here:

   

Out of "suspicion" that the Outlook OST File or Profile was corrupt, we turned off Cached Mode (Cached Exchange Mode) and verified that there were no Sent or Outbox Items pending to be sent.

Without doing anything else, we re-enabled Cached Mode and opened Outlook - suddenly over 50 previously sent Emails suddenly appeared in the Outbox about to be sent again!
So it's without doubt that there is corruption somewhere along the line and that "Cached Mode" is a major factor.

There is a lot of misleading info out there on DuckDuckGo (more so on Google) leading to Exchange as the cause.
For us it was not Exchange but Outlook.

Due to the age of Outlook a permanent fix is not going to be pursued - we are simply going to disable "Cached Mode" until executive decisions are made to upgrade the Office Suite.