Many administrators in small environments (where we have Essentials server) have to buy a trusted certificates to make RWW working. The common problem of all those environments is, that there is no money for buying certificates or owners don’t understand why they need to buy certificates. This is why I am writing a post how to certify RWW with Let’s encrypt certificates.
It is a bit different to do it because Let’s encrypt certificates have validation period only three months and maybe it seems, you will have a lot of work – but don’t be afraid; we have two ways to simplify this procedure and my preferred procedure is with a product called Certify.
- First download Certify from this link (https://certify.webprofusion.com/).
- Install Certify with default options as you can see on screen shots. There is no need to change any settings; the application is simple and can be always installed with default options.
- Now you have to modify Essentials server configuration. Certify can issue the certificate banded to name of default web site in IIS. This means that we have to modify default site bindings (look at picture) in a way that we have public RWW name bind to default web site and port 80 – 443 SSL is not needed.
- For the first time, when you enter Certify, you will need to add your contact details. It is just to care about your certificates.
- Open Certify and start registering the new certificate.
- From the form select default web site and clear checkbox from local server name.
- CLick Save.
- Click Request certificate. At this point you will receive the certificate – be careful on firewall rules; you need to open port 80 and 443.
- We have now to do the last step: go to Configure Auto Renew and type Username and Password for user who is able to request the certificate.
That’s all you need. Now you have configured RWW with free trusted certificate, the certificate will be renewed automatically when will expire and you don’t need to manually renew it anymore.
The same process can be done on any IIS website or for any certificate that could be requested thru IIS.
Many administrators (including me) are not happy with two services in Server 2016. This services are OneSyncSvc (synchronizes mail, contacts, calendar and various other user data) and Download Maps Manager (for application access to downloaded maps) and are really not critical on server OS.
This is the reason why, you can disable them in almost all cases without any deep research. Anyway, when you try to disable OneSyncSvc from services console, you will receive an error, as this service cannot be disabled. At this point, use a trick and disable both services form elevated command prompt using commands:
sc config “OneSyncSvc” start= disabled
sc config “MapsBroker” start= disabled
Of course, before you run this commands, services have to be stopped, otherwise you will receive an error. You can do this also from command prompt:
sc stop “OneSyncSvc”
sc stop “MapsBroker”
This two simple commands will put services into startup type “disabled” and errors in Server Manager that are related to non-running services will disappear. Problem solved.
If anyone tries to install the new Microsoft ADK (for Windows 10 Version 1703 – 10.1.15063) on Windows server 2016, you receive the error that a driver is not digitally signed. Well, Microsoft drivers are not signed? Something is wrong…
Actually, according to this post, they really have a problem and there is a workaround with disabling the secure boot. But this is not recommended and is not aligned with best practices – so you don’t want to do it.
Anyway, this is the only way you can install ADK on server 2016 and I did it. I have removed the previous (broken) installation, disabled Secure boot and reinstalled ADK. After a successful installation, I reenabled Secure boot and things still went wrong. I was unable to mount ADK boot image (to use in SCCM or MDT). Well, in this post it is explained another workaround (yes, I know…). Set the registry as is explained and it should work. I just hope that all other functionalities in ADK now are working OK.
In addition to my previous post on reestablishing synchronization of SYSVOL folders between DCs, I received some comments that going true steps in the posts is not possible to reestablish sync. After this I diagnosed some situations when friends allowed me to connect and there was always a similar situation: DFS replication stops to work after dirty shutdown (event 2212 and 2213) and nobody saw it for a long time – more than 60 days. This will cause an Error 4012 where you can see that the server was “disconnected” for a time, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60 days by default).
To verify how long are DCs not synced, use this command line (execute from elevated command prompt):
For /f %i IN (‘dsquery server -o rdn’) do @echo %i && @wmic /node:”%i” /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
If the result is more than 60 days, you have to extend MaxOfflineTimeInDays parameter on all servers where you have DFS replication in error (State = 5) and where MaxOfflineTimeInDays parameter is greater than 60. Use this command line on any DCs that are in error:
wmic /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=365
Of course you can replace the number 365 with any number you want, but it has to be greater than the displayed MaxOfflineTimeInDays value.
Wait for few minutes and resume replication as is described in the previous post. It should work.
I suggest also to put back the value MaxOfflineTimeInDays parameter to previous value:
wmic /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60
Of course you have heard about the new malware, which yesterday created a lot of problems in industry. Unfortunately it is not an unknown problem.
Microsoft released a patch for this type of vulnerability already in March, but it seems once again that administrators are not patching their systems.
So, if you haven’t patched your systems at least every month, if you haven’t patched your system from March, is time to do it. And don’t forget to have a good defense system (antivirus and other prevention mechanisms). Update them to!
You can find additional information in this link.
Here is a link to post how was neutralized and who did this.
Anyway, we have already a version 2.0; you can read about this version here.
Again, please patch your systems! This update will solve a vulnerability. And don’t forget: this is not the first malware who was written on known vulnerability – patch your systems constantly!
Additionally, please disable SMB1 protocol – it is not new that it is not secure. Here and here are some guidelines how to do it via GPO.