Windows 1803 Version
Marguerite Gilbeau
Windows 10 April 2018 Update[1][2] (also known as version 1803[3] and codenamed "Redstone 4") is the fifth major update to Windows 10 and the fourth in a series of updates under the Redstone codenames. It carries the build number 10.0.17134.
The first preview was released to Insiders on August 31, 2017. The final release was made available to Windows Insiders on April 16, 2018, followed by a public release on April 30, and began to roll out on May 8.[4][5]
The update has reached end of service on November 12, 2019 for Home, Pro, Pro for Workstations and IoT Core editions.[6] The Enterprise, IoT Enterprise and Education editions would have originally reached end of service on November 10, 2020, but this was postponed to May 11, 2021 due to the "global health crisis", in reference to the COVID-19 pandemic.[7][8][9]
This is a brand new clean install of Windows 10 1803 that I did for testing on a VM. One thing to note is that I did set TargetReleaseVersionInfo to 1803 to ensure that it didn't upgrade before I switched to Intune. That was just removed Monday so at this point its only been a few days.
As for the Report it shows Offering, but a few things stand out but both of these could be related to running an outdated version of Windows 10 since you need 1903 or later for the Compliance Reports.
Sooo ... is an upgrade from 1709 to 1803 even possible? It is a little crappy if we have to reinstall the half year releases from scratch every time ... I understand this would be less of an issue if we use the non-lts windows versions solely as container images, but I would like to run this on my server as well ...
So you are saying that Windows Server 1709 Core that has been running my server since it was released in september 2017 is not an RTM version of Server 2016, but 1803 is? That does not make any sense.
It's like 1709 was just swept under the carpet? Or should we expect to reinstall version 1809, 1903 and 1909 as well, when they will be released? That reduces the usability of the semi-annual core versions to be something that we use as the basis of our container images, where we can just bump the version number in docker files ... seems like a bit of a problem to me.
However, it looks like they dropped that feature when they announced, in late March, that the SAC versions would be focused entirely on "modern applications and innovation scenarios such as containers", and would drop most of the infrastructure roles.
Accordingly, 1803 has even fewer infrastructure services than 1709 (which dropped Storage Space Direct just as it was released). So an in-place upgrade would have likely stripped out features from a 1709 installation, causing issues for administrator who (rightfully) expect an in-place upgrade to maintain roughly the same feature set.
@Dave Patrick, I just want to make sure that this is clear for everyone. There is no such thing as Windows Server 2016 1803. There is only one RTM release of Server 2016, and that was 1607. There is Windows Server 2016 and then there is Windows Server 1803. You must view them as two different product offerings.
The Windows Server releases with YYMM build numbers, like 1607, 1709, 1803, etc... are part of the windows semi-annual channel (SAC) and will be released every six months. These releases will be bleeding edge releases and will not support the GUI interface at all, only a core install. They will only have a support life span of 18 month. Even though there is cases of engineers upgrading a SAC deployment to the next release, this is not supported and MS is expecting you to deploy brand new installs when the new version is released.
The Windows server release with the actual year referenced are the Long Term Servicing Channel. They are what we are used to seeing released every so many years, 2012, 2016, 2019, etc... They will include some of the technologies that have been released in the SAC channel that have been deemed production stable and supportable. These releases will have the normal mainstream support of 5 years. These releases on the other hand can be upgraded from old to new releases.
When I run the Windows 10 1803 in-place upgrade, it fails because Bigfix sends an unexpected restart. The restart appears to be from the upgrade action itself. I took the action and the machine restarted, but then it restarted again in the last phase of the upgrade which causes the upgrade to roll back.
In the Windows upgrade log, there is a roll back folder with event logs. The system event log shows that the Bigfix task for the upgrade causes the restart at the time the upgrade log stopped recording.
Thanks. I will look at the other posts. I am curious to find out how removing the /NORESTART could possibly work. It seems like the machine is going to restart on the user when they are in the middle of their work, unless the upgrade displays some messages. Since we are running in silent mode, I would not think that messages would be displayed.
READ CAREFULLY: Your system is running an older version of Windows 10 and this update will bring it up to Version 1803. Upon Taking Action, the update will start, run about 25 minutes, and REBOOT WITHOUT ANY FURTHER NOTICE. You may want to only Take Action when you will not need your computer for about 60 minutes. For example, before going to lunch.
I saw your post earlier regarding the restart bug. I think it is unacceptable for IBM to say it is a Microsoft problem and not do anything about it. IBM needs to work with Microsoft or create a work around for the problem. Bigfix strength is supposed to be deploying updates which is very difficult with this restart bug.
There needs to be something built into Bigfix to check for a running Windows upgrade, and not execute any actions during an upgrade. I also have a problem with other actions running that will cause the in-place upgrade to fail. For example, the September Microsoft updates. In the third phase of the upgrade, Windows is on the network, but the upgrade is not complete. Bigfix can an does send updates during that third phase. If there is a restart in one of those actions, the upgrade will fail.
For the messaging approach, it might help if you add a running message so the user knows that it is still running. There was a setting added around 9.5.7 timeframe that allows you to make running messages persistent (not dismissible by the user).
Do you think it would work to have a policy running whose only purpose is to display a message letting the user know they need to restart the PC, then after 24 hours persist the message in the foreground? The relevance would be:
The only problem with the messaging approach is that it depends on the user being there. We would like to complete most of our updates overnight without disrupting the user. We would instruct the user to log off their PC before they left at night, and the upgrade would run from beginning to end. For any users who had forgotten to log off, we would send a logoff task, and then the machine would restart and complete the update.
Baseline that will not have NORESTART on the command-line. When we run this baseline, it will have a time window to limit when it runs. The intent is to have a job that will complete the upgrade from beginning to end overnight without disrupting the end user.
There is an issue when I put the persist message setting in the upgrade baseline. The problem is that the non-persistent message will appear initially, then it disappears, and then the persistent message will appear. Is there a way to get around this within the same baseline, or am I going to have to have an upgrade preparation baseline and then run the upgrade task independently?
Hello, I am on Win 10 1803 and I've been letting updates go through and rebooted many many many times, so I believe I am up to date. I cannot install 4.7.2 of .NET because it says I already have it or a newer version installed.
I have Defender and Malwarebytes, but those are off. I get to the part of the install where it says "Preparing to install" and just gets stuck there for 10+ minutes (this is to an SSD, even). I even tried a slightly older version, but that didn't work. Any other ideas?
I tried booting into Safe Mode as suggested and running the paint.net installer, however that does not work at all. After running the installer, the first thing is an error message from the .NET installer window saying 1) that .NET installer is not supported in safe mode 2) already running a newer .NET version, and a 3rd error which I don't remember.
From what I'm understanding, is that it appears your (4.0.21) Paint.net installer is forcing the 4.7.1 .NET Framework installer to run first, on a Windows 10 OS which already has a *NEWER* version installed, and the 4.7.1 .NET Framework is probably failing to complete with this error:
But the way that I got the screenshot above, is that I went into "C:\ac71d656454cd1fa798a7ed3e2" directory (which is where the paint.net installer is being unzipped to) and manually tried to run Setup.exe, which launches the Microsoft .NET Framework installer. And the SetupUtility.exe for .NET 4.5 does not run at all.
Basically, I think your installer is broken on the newer Windows 10 releases, because its trying to force the installation of older .NET versions (which fails miserably) since the built-in .NET cannot be modified by an external installer, and so we're never even getting to the installation of paint.net.
c80f0f1006