In some cases, you need to establish VPN before you login to Windows. As some VPN clients offer this method (not all of them, of course), I had a requirement to create this option with Windows build in client.
Here I found a trick; If you want to create VPN connection thru Windows settings, it will not appear on logon screen and this is not useful for me. If you create VPN thru network and sharing centre it is different – VPN connection appears on logon screen. Makes sense? No, but if you need it, is good to know how to configure it.
So, here you can follow the step by step instructions:
- Open Control Panel
- In Control Panel click View Network status and Tasks
- In Network and Sharing Centre you will find a wizard to create a new VPN connection by clicking on Set up a new connection or network. It is almost the same as in other ways, but if you create VPN here, it will appear on the start screen. It is important, that you create VPN for all users!
- On the Set up a Connection or Network wizard you have to choose Connect to workplace
- On the next step you can use an existing VPN connection or create a new one. If you already have a VPN configured, you can just modify it. In my case I will create a new one (I prefer always to create a new connection). If I have an old configuration, I always delete it and recreate a connection from the scratch
- On How do you want to connect, choose Use my Internet connection (VPN)
- Write the name or IP of the VPN endpoint, destination name and do not forget to check Allow other people to use this connection. Then click on Create
- If you want to do additional setting on this connection (specify protocol, add certificate …), you have to open the ncpa.cpl (Network Control panel) and from there you can review or change all settings you want
A connection done in this way will appear on logon screen and it is possible to establish VPN before you login in Windows.
Lately I had a lot of problems with TLS 1.0 standards, which have changed. For a lot of secure applications you have to disable TLS 1.0, if you want the connection to work.
Well, set settings for any user it makes no sense and the only acceptable way it is thru GPO settings. There is no real setting for change-enabled protocol (you have to do it in Internet Explorer settings). The only way I found was changing the registry value of SecuredProtocol, located in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings.
But here is only a numerical value and I had to find how is it calculated. I found some values in an article and from here you can calculate the desired value. The basic numbers are:
0 = Do not use secure protocols
2 = PCT 1.0
8 = SSL 2.0
32 = SSL 3.0
128 = TLS 1.0
512 = TLS 1.1
2048 = TLS 1.2
If you want to enable more protocols, just sum the desired numbers. For example, to enable TLS 1.1, TLS 1.2 and SSL 3.0 is 512 + 2048 + 32 = 2592. This is a decimal value for a registry key SecuredProtocol. Deploy a registry value true GPO and the setting is done.
On January 4th, Intel processor vulnerability was published. It is a vulnerability that affects not only Microsoft systems, but also all other systems, including iOS, Android, Linux etc.
I won’t spend the same words as you can read them in many published articles about the vulnerability and how serious it is. I just want to share two links, where is it possible to find tools / patches for Microsoft systems:
https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution (PowerShell must be 5.1 or higher)
It could happen. I saw this issue couple of times, not only on domain controllers, but also on other domain joined computers.
The cause of this problem is the Network Location Awareness service. We know, that this service is recognising network location based on gateway and is trying to locate AD server thru port 389. Well, when gateway is changed or no server connection true port 389 is available, we have a new network location – by default it is Public.
Anyway, it can happened that NLA service starts before the AD services are started (or before DC is reachable on a non DC server). In this case, we will have public network profile on DC or domain joined computers. If firewall is enabled, most of network services will not run as the firewall for the Public profile is almost closed.
We have few possibilities to solve this situation. Maybe the most simple way is to restart the server, but I don’t know if I can restart the server at this moment and what was the original cause of the problem – maybe it will reappear. The second option is to disable / reenable the NIC adapter and in most cases, it will solve the issue. We will get the same result if we just restart the NLA service – this is a better way.
In some cases, you cannot connect to the computer for some reason. In this case, I use PowerShell remote session to solve the problem.
Here are the steps:
Enter-PSSession ComputerName (establish connection to computer with the problem)
Get-NetConnectionProfile (this will show you your current location profile – if this is the source of the problem, the location will not be Domain)
Restart-Service nlasvc (this cmdlet will restart NLA service; after this step you should see Domain network profile)
Get-NetConnectionProfile (just to check if the solution works)
Exit-PSSession (disconnect form the remote computer)
Based on my experience, this solution works always. Some administrators also suggest to change start option for NLA service to Automatic (Delayed Start). I am not sure if this is a good solution; be careful with it. Maybe you can do it in cases where this error is frequent (better: search for the original cause and solve the problem)
Azure File Sharing (AFS) is a new technology, currently in public preview, used for caching files or syncing file servers or cluster around the datacentres. If you want to know more about useful scenarios where to use AFS, I suggest you to read this blogpost or watch this video.
In this post, I will explain how to install AFS on a server to be synchronized with Azure. I will go thru installation of the first server, but installing agent on the second or any other server is just the same process as for the first one. Of course, you must have an active Azure subscription (you can open a trial, but this will be time limited – maybe just for testing) and a supported server OS – Windows server 2012R2 or Windows Server 2016.
First step is done in Azure. Here we have to prepare the Storage account:
- Login to Azure portal
- On the Left side menu select +New, in Marketplace select Storage and then Storage account and click Create.
- Write the Name of the account, the Account kind MUST BE »General purpose« and Replication »Locally-redundant storage (LRS)«. Set Storage Service encryption and Storage Transfer required to »True«.
- You can create a new Resource group or use the existing one.
- Use one of the supported Locations. (list)
Now we have to create an Azure File Share:
- Navigate to Storage account that we have created previously
- In Overview find section Files and click on + File Share
- Write the Name and click Create.
As last, we have to create Storage Sync Service:
- In Azure Portal, click on +New, in search box type » Azure File Sync«, select Azure File Sync (preview) and click Create.
- Fill all fields, use the same Resource group as in Storage account and click Create.
For now, we have finished to prepare the Azure part and we will move to our on premises server. We will install Agent here and test prerequisites.
First, we have to find if our server has all that we need to install the agent:
- We will need PowerShell version 5.1 or higher. You can check this from PowerShell with cmdlet $PSVersionTable. If PSVersion is lower than 5.1, then you must upgrade PowerShell by installing WMF 5.1 Package (install Win8.1AndW2K12R2-KB3191564-x64.msu)
- Install AzureRM cmdlets with installing PowerShell module: Install-Module AzureRM (Answer Yes to continue and to install from untrusted repository – it is a preview).
- Register AFS provider: Register-AzureRmResourceProvider -ProviderNamespace Microsoft.StorageSync. In case that you receive this error, run cmdlet Login-AzureRmAccount
- Disable Internet Explorer Enhanced Security Configuration (you should do this because you have to login into Azure later).
Now we will install the agent on the server that we want to sync:
- Download agent installation from Azure portal
- Run the installation wizard
- On a welcome page click Next, accept the license agreement and click Next.
- On the Feature selection you can change the location for the files and click Next
- Consider using Windows Update services to update the AFS agent (it is already a part of MS Updates) and click Next
- Click Install
- After the installation is finished, the server registration will run. If this will not happen or you want to run it manually later, you can search for file ServerRegistration.exe and run it.
- In Server Registration, sign in to Azure with your Azure subscription (this step will open an Internet Explorer window to sign in process)
- Select the needed data (Subscription – if you have more than one, Resource group that you used in previous steps and Sorage sync service that you created before)
- Click Register.
- After successful registration, you completed a server agent installation, server registration to AFS service.
We have now created Storage Sync Service, installed agent on our server and registered our server to created Storage Sync Service, but we haven’t yet configured the synchronization between Azure and on premises servers – so synchronization is not working in this moment.
We have to add Azure server as an endpoint in Sync Service. The easiest way to do this is in the Azure portal:
- Login to Azure portal
- Navigate to Storage Sync Service we created and in Overview click on +Sync group.
- Type all data and click Create.
- Click on Sync group you created and add Server Endpoint
- When you are adding server Endpoint, you have to enter FULL LOCAL PATH on the server and the percent of free disk space on local server (can be different for any server).
Done! You have now created Azure File sync and you have just to wait for the first sync. Of course, it can take some time – depends on the amount of data, but after this you will have all your files safe in Cloud. For this reason, you can use this service as a DR scenario.
If you want to add an additional server to the same AFS service, just repeat all steps that were done on the local server and register it to existing AFS account. Different server scan host locally different files (depends on usage), can be member of different domains or workgroups – so you can use this technology for some collaboration projects as well.