Manage FISMO Roles with PowerShell


How to use PowerShell commands to transfer FISMO roles?


Active Directory PowerShell module.


FISMO PowerShell management requires Active Directory PowerShell module.

  Import-Module ActiveDirectory

Example 1.  Show forest FSMO roles (forest):

PS> Get-ADForest| ft DomainNamingMaster, SchemaMaster

Example 2.  Show domain FSMO roles (domain): 

PS> Get-ADDomain | ft InfrastructureMaster, PDCEmulator, RIDMaster

Example 3. Transfer single role to a domain controller.  

PS> Move-ADDirectoryServerOperationMasterRole -Identity "DCX" PDCEmulator

Table1:  PowerShell FISMO role names:

PDCEmulator         0
RIDMaster         1
InfrastructureMaster 2
SchemaMaster 3
DomainNamingMaster 4

Example 4.  Transfer multiple roles.

Move-ADDirectoryServerOperationMasterRole -Identity “DCX” –OperationMasterRole DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster

Example 5: Transfer all roles with numbers: 

Move-ADDirectoryServerOperationMasterRole “DCX” –OperationMasterRole 0,1,2,3,4

Example 6.  Transfer FSMO roles between domain controllers:


That's It!


Fix Win NAT-T for L2TP and IKEv2


Windows 2012 RRAS IPsec VPN does not support NAT-T out-of-the-box.  By default, RRAS only works with public IP addresses -no NAT.  Windows 10 clients cannot connect with L2TP from outside the office.  Windows 2016 does not support L2TP for any client from behind routers running NAT.


Enable NAT-T on both Windows servers and the clients.  NAT-T allows the VPN server to serve clients (e.g., Windows 10, Android, Apple iOS) from behind the NAT device.  Modify MTU. 


Why NAT-T? 

IPsec uses Encapsulating Security Payload (ESP) to encrypt packet headers and payloads.  By default, ESP is not compatible with Port Address Translation (PAT).  This is because TCP uses ports and ESP does not.  

TCP and ESP are different Internet protocols. TCP uses protocol number 6.  N.B., TCP protocol number 6 is not the same thing as TCP port 6.  TCP ports are communication endpoints.  For example, TCP uses port 80 for web traffic.  

ESP uses protocol (i.e., not port) number 50.   ESP is a protocol without ports.  Network Address Translation (NAT) uses port translation PAT to bind traffic flows with internal hosts.  Therefore, ESP does not work with NAT.

NAT-T allows ESP to work from behind NAT.  It encapsulates ESP protocol 50 inside User Datagram Protocol (UDP) 4500.   N.B, NAT-T is not the same as IPsec over UDP.

Enable NAT-T 

NAT-T is enabled on most operating systems (e.g., Android) -Windows is the exception.  Fortunately,  we can enable NAT-T on Windows 10 and Windows 2012 with a few simple changes. 

Windows IPsec clients are supposed to work from any location.  Therefore, only enable NAT-T on the 2012 RRAS server.  

Create a new registry key to enable NAT-T.

  1.   Edit Registry or create GPO:


  1.   Create new DWORD value:   AssumeUDPEncapsulationContextOnSendRule

  1.   Modify DWORD value:  2

These changes will fix those pesky L2TP-NAT problem.  

Troubleshooting Issues

Make sure clients use the latest edition of Windows 10.  Early versions had quirks where clients simply would not connect via NAT-T.  

   NAT-T does not work with  the following editions:

  • version 10240
  • version 1511 (i.e. November Update)
   Unconfirmed (may or may not work):  
  • version 1607 (i.e., Anniversary Update)

  • version 1703 (i.e., Creators Update)
   NAT-T works great with the registry fix and Creators Update.


Some folks had to toggle the NAT-T registry value in order to connect (  I assume this fix was for the November or Anniversary Update.  


Don't forget to adjust the Max Segment Size (MSS):  

That's It!

S4B Clients on Split-Tunnel VPNs.

S4B:  Bypass Split-Tunnel VPNs.

Take Away:  

Skype for Business (S4B) and Lync clients may experience problems when traversing a split-tunnel VPN.  Use Name Resolution Policy Table (NRPT) and Windows firewall group policies (GPOs) to bypass split-tunnel VPNs.  This solution is easy to administer and provides remote offices the best multimedia experience.


The DCA office experiences weird S4B/ Lync issues:  

  • Local S4B/ Lync clients cannot host conference calls for external clients.
  • All clients (external and DCA) can connect to conference calls hosted at at the company headquarters (JFK).  
  • Local S4B/ Lync clients cannot share multimedia content (e.g., screen-sharing, video, etc.) between external clients.  
  • All clients can share multimedia content when connected to conference calls hosted at JFK HQ.
  • Audio and video quality is poor (e.g., choppy or static) between DCA and JFK locations.


This business consists of two locations: JFK is the primary HQ office.  DCA is the branch office.
  • A site-to-site IPsec VPN tunnel connects the DCA and JFK offices.  
  • DCA uses split-tunneling to forward all corporate data.
  • DCA uses its default gateway to forward all other traffic to the Internet.  
  • JKF hosts all Lync servers:  Front End, Access Edge, and Reverse Proxy servers.
  • Both DCA and JFK use Active Directory (AD) integrated DNS servers.
  • External clients allow staff to work from home.
Figure 1.  Example of  Lync and organization topology.

ICE Framework:  

S4B-Lync uses network topology to select the best connection path.  It uses a peer-to-peer connection framework called Interactive Connectivity Establishment (ICE).   This framework includes Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) protocols.

STUN identifies client Network Address Translation (NAT) (i.e., private IPs). This process also identifies the default gateway (i.e., public IP).  Multimedia travels directly between end-points when STUN is used.  S4B/ Lync clients prefer to communicate directly (i.e., peer-to-peer) between clients which reside on the same LAN.  N.B., LAN is not a reference for broadcast domains.  LAN, in this situation, includes all internal networks (i.e., subnets) with routes to the Front-End subnet.  Internal clients never use the Access Edge server for internal communication. 

Similarly, external clients prefer STUN for communicating multimedia content to other external peers.  The Access Edge server will only bridge external-to-external clients (i.e., TURN) if peer-to-peer communication is not possible.

Lync clients use TURN framework when end-points do not share a common LAN.  The TURN process creates dynamic ports on the Access Edge server; and in turn (pun), proxies external multimedia.  TURN is similar to Port Address Translation (PAT), just as the Access Edge server is similar to an Internet gateway.

To recap, S4B/ Lync clients prefer direct peer-to-peer multimedia communication.  Internal clients will never use the Access Edge server for internal multimedia communication.  External clients use the Access Edge server to bridge communication whenever peer-to-peer communication is unavailable; including external-to-external, and external-to-internal.

Split-Tunnel Problems:  

ICE framework (generally) provides the best multimedia experience.  However, it does not work well over split-tunnel VPNs.  Split-tunnel VPNs create STUN and TURN mismatches.  For example, the DCA branch office firewall forwards all domain traffic to the JFK primary office; all other traffic forwards out the local gateway (i.e., Internet).  DCA and external Lync clients interpret this topology differently (Table 1).

Table 1. 
Default Multimedia Network Traffic Between Lync Clients
     Source           Destination
JFK DCA External Client
External Client TURN STUN STUN
Notes:  DCA uses split-tunnel VPN to connect to JKF.  Stun represents Lync client-to-client.  TURN represents multimedia proxy (i.e., Lync Access-Edge) requirement.    Blue represents split-tunnel topology.  Red represents client topology mismatch.  

The primary problem with split-tunnel VPNs is with how the S4B/ Lync client interprets the topology.  Recall, internal clients always use the Access Edge server for external communication.  Likewise, internal clients never use the Access Edge for internal conversations.  The VPN firewall forwards all domain traffic to the JKF network.  Therefore, DCA clients consider themselves as internal; and external clients as external.  DCA clients will only use the Access Edge server when communicating with external clients.

External clients have an entirely different interpretation of  the topology.  External clients are aware of the DCA Internet gateway, but they remain unaware of its split-tunneling.  External clients will therefore interpret DCA clients as external peers; multimedia traffic is sent directly to the DCA clients (i.e., STUN).

To recap, external clients are unaware of the DCA split-tunnel.  These external clients attempt to send audio and video (AV), and expect to receive AV, directly from the DCA clients.  Whereas DCA clients send AV, and expect to receive AV, proxied from the Access Edge server.

Figure 2.  Lync directional mismatch.

The split-tunnel VPN causes a secondary problem between JFK and DCA.   These clients use STUN to establish peer-to-peer connections across the VPN.   Users complain about overall client AV quality between these locations.

Multiple layers of encryption decreases overall AV quality.  Lync encrypts multimedia packets with TLS and SRTP protocols.  The VPN adds additional packet overhead as it encrypts and encapsulates each packet.  Staff at both locations can expect better AV if  DCA S4B-Lync clients bypass split-tunneling (i.e., TURN).

Figure 3.  Bypass the split-tunnel VPN.


S4B-Lync clients can bypass split-tunneling entirely:  (a) changes to DNS topology; and (b) changes to client firewalls.  Recall, both offices belong to a single AD domain, and each office uses recursive AD integrated DNS servers.  AD replication ensures internal name resolution is the same at each location.  Lync clients use DNS to locate S4B-Lync servers via S4B-Lync Discovery (Table 2). 
Table 2. 
S4B-Lync Client Discovery Preference Order
DNS Prefix lyncdiscoverinternal lyncdiscover
Discovery Order 1st preference 2nd preference
Client Internal clients External clients
Server Front-End Access-Edge
Notes:  Discovery preference assumes organization uses a split-brain DNS topology.  Topology consists of independent internal and external DNS servers.
  All internal clients, including those on the VPN, use internal DNS for Lync Discovery resolution.  External clients use external DNS for their Lync Discovery process.  Therefore, VPN clients can bypass split-tunneling using a process that distinguishes Lync traffic, and resolves it using external name records.  N.B., Internal DNS continues to resolve all other (i.e., non-Lync) requests.  Otherwise, what's the point of having a VPN?    

Name Resolution Policy Table:
  Split-brain DNS requires a confusing array of zone records.   Most Internet documentation suggests pin-point DNS zones to influence Lync traffic.  Instead, consider using NRPT, which simplifies the entire domain resolution process. 

Lync clients can bypass the VPN with NRPT group policy.   NRPT is configured with two simple rules:
  1. Forward all domain name requests for Lync services to external DNS servers.
  2. Use client DNS settings (i.e. internal)  for all other DNS resolution.
Create the NRPT Group Policy to allow S4B-Lync clients to bypass the VPN:
  1. Create new GPO:  Computer Configuration → Policies → Windows Settings → Name Resolution Policy.

  2. Configure the Advanced Global Policy Settings: 

    Figure 4.  NTRP GPO to bypass split-tunneling.

  3. Change the Query Resolution settings.  Enable "Configure query resolution options".  Enable Resolve both IPv4 and IPv6 addresses for names.

  4. Create rules that forward Lync FQDNs to external DNS servers.

    a.  To which part of the namespace does this rule apply?  Choose FQDN.
    b.  Click on the Generic DNS Server tab.
    c.  Toggle the Enable DNS settings check box
    d.  Click the Add button
    e.  DNS server:   Enter an external recursive DNS server; or the authoritative public (i.e., Internet facing) DNS server for your organization's sip-domain.
    f.  Click Apply.

   GPOs are applied to AD domains, sites, or Organizational Units (OUs).  In most situations, it makes sense to apply the NRPT GPO to the AD site that correlates with the branch office.

   From Group Policy Management:  Right click on Sites → Left click on Show Sites → Right click on the branch office site → Link an Existing GPO.     

   Alternately, create separate computer OUs per location.  Link the NRPT GPO OU that nests all branch office computers. 

Windows Firewall:

   NRPT influences clients to logically bypass the VPN.  However, there may be circumstances when Lync clients discover alternate (i.e., split-tunnel) paths to internal resources.  Lync clients, therefore, require both logical and physical divisions.  Windows Firewall compliments the NRPT GPO with two simple rules:
  • Restrict traffic based on application (i.e., S4B).
  • Restrict traffic based on source (i.e., DCA) and destination (i.e., JFK).
Create the Windows Firewall GPO:
  1. Create new GPO:  Computer Configuration → Policies → Windows Settings → Security Settings → Windows Firewall with Advanced Security → Inbound Rules.
  2. Right click on Inbound Rules → New Inbound Rule → Program → Path:  %ProgramFiles%\Microsoft Office\Office15\lync.exe → Block the Connection → Apply rule to Domain.  N.B, Use applicable application paths.  For example, Lync Basic and Lync Professional may use different paths.
  3. Edit the new Inbound Rule:  Right click on the new rule → Click on the Scope tab → Add all internal IP subnets (i.e., primary office) to the Remote IP address field → Click Add → Click OK.

    Figure 5.  Windows Firewall GPO to bypass VPN.

  4.  Apply the newly created Firewall GPO to apply the AD site that correlates with the branch office.  Alternately, apply this GPO to OU that nests branch office computers.


   NRTP and firewall GPOs force S4B-Lync clients to bypass split-tunnel VPNs.  These combined GPOs have two primary effects:  (a) DCA-to-external clients prefer STUN (i.e., client-to-client); and (b) DCA-to-JFK clients use TURN (i.e., client-to-Access Edge) for external AV communication (Table 3).  

Table 3. 
Effects of  Split-Tunnel GPOs on Multimedia Traffic 
     Source           Destination
JFK DCA External Client
External Client TURN STUN STUN
Notes:  DCA uses split-tunnel VPN to connect to JKF.  Stun represents Lync client-to-client.  TURN represents multimedia proxy (i.e., Lync Access-Edge) requirement.  Blue emphasizes branch office traffic.   

That's It!

Windows IKEv2 MTU


How to set MTU on Windows Servers.  Windows Server 2012 VPN fragments packets after it applies encryption!  This issue causes latency and causes the VPN to disconnect clients -no good!


The default packet size is 1500.  Now consider how IPsec encryption adds a number of bytes to the original packet.  This process leads to post-fragmentation conditions.  In other words, packets are fragmented after encryption.  This condition degrades or disrupts VPN performance. 


Adjust maximum segment size (MSS) on the outside interface so packet size is less that the default 1500 MTU.

Packet fragmenting occurs when a packet is larger than its default MTU.  TCP fragments the original data and sends it avoid encrypted packet.  According to Cisco, ESP overhead adds a maximum of 73 Bytes to each packet.  Therefore, we can adjust the MSS to a conservative 1400.


Step 1:  Identify external interface.

PS C:\Users\thedude> netsh int ipv4 sh int

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 29          30     Default  connected     RAS (Dial In) Interface
 12           5        1500  connected     Inside
 14           5        1500  connected     Outside

Step 2.  Modify external interface MSS.

PS C:\Users\thedude> netsh int ipv4 set subint "Outside" mtu=1350 store=persistent

Step 3.  Confirm MSS:
PS C:\Users\thedude> netsh int ipv4 sh int

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 29          30     Default  connected     RAS (Dial In) Interface
 12           5        1500  connected     Inside

 14           5        1400  connected     Outside

That's It!


Door Wide Open on Win IKEv2

Fix for Windows VPN Certificate Authentication Vulnerability


Windows Server 2016 VPN server has left the front door wide open for attackers –by default!  It authenticates ANY client certificate issued by ANY public CA.  This problem occurs when the client certificate trust chain matches a certificate in the server’s trusted root store.  For example, an attacker can authenticate with any DigiCert certificate (Figure 1).
How vulnerable are these servers?  I'm willing to wager that my twelve-year old son can hack it in under five minutes.  This is a pants-on-fire security hole that needs to be fixed before the server hits production.

Figure 1.  Win IKEv2 authenticates with ALL root CAs.  Yikes!
N.B., Take additional precautions to secure your VPN:

There are two ways to fix this serious IKEv2 flaw: 
  • Remove public CAs from the Trusted Root certificate store.
  • Use PowerShell so RRAS only authenticates certificates issued from our private CA.

Certificate Store Solution: 

Use Windows CA or OpenSSL CA servers, etc.  DO NOT use a public CA.  Remove ALL public CAs from the server’s trusted root store.  Turn off automatic certificate updates.  Implement additional authentication safeguards.

Step 1:  Only use private certificates (e.g., Windows CA) –do not use public CAs. 
We won’t cover the entirety of installing a CA in this article.  However, it’s important to understand that the private CA root certificate resides in the Trusted Root certificate store –on both servers and clients.  

Step 2:  Edit Trusted Root Store:
Start → Type MMC → File → Add → Certificates → Local Computer → OK.
  • Backup your system.
     •    Exporting root certificates before you delete them –just to be safe.
     •    Take a system checkpoint if applicable.
  • Certificates to keep:
           •  Microsoft Root Authority 12/31/2020 -required
           •  Thawte Timestamping CA 12/31/2020 -required
           •  Microsoft Root Certificate Authority 5/9/2021 -required
           •  Private Root CA

  • Delete all other certificates in the Trusted Root Store.

Step 3:  Create new GPO that prevents certificate updates.
Edit GPO: 
   → Computer Configuration 
      → Policies  
         → Administrative Templates 
            → System 
               → Internet Communication Management 
                  →Internet Communication Settings 
                     → Turn Off Automatic Root Certificate Updates:  Enabled.  

PS Solution:

Is there a better method?  Until recently, there was no way to assign specific trust chains for IKEv2 client authentication.  The system was simply all or nothing.

Thankfully, Microsoft now provides a solution that fixes this authentication vulnerability.  We can finally configure specific root certificates for authentication purposes.  N.B., This solutions assumes we’re using a private CA for authentication.  Also not, that Microsoft documentation states that this method is only for site-to-site (S2S) VPNs –not true!

Step 1:  Confirm existing VPN authentication settings:  Get-VPNAuthProtocol (Figure 2):

Figure 2.  Confirm IKEv2 authentication with Get-VPNAuthProtocl.
The RootCertificateNameToAccept field should not be empty.  If so, your sever trusts ANY client from ALL Public CAs in the Trusted Root store.  Let’s fix this!

Step 2:  Configure the VPN server so it only authenticates certificates issued from our private CA:
PS C:\Windows\system32> $cert1 = ( Get-ChildItem -Path cert:LocalMachine\root | Where-Object -FilterScript { $_.Subject-Like "*THWATE*" } )

PS C:\Windows\system32> Set-VpnAuthProtocol -RootCertificateNameToAccept $cert1 -PassThru

WARNING: Configuration parameters will be modified after the Remote Access service is restarted.

The above example uses a variable that assigns a root certificate (i.e., issuer) from our Trusted Root store.  It requests a certificate that has “THWATE” in its subject.  This is for demonstration purposes only.  Do not use THWATE in your configuration.

Successful execution always provides output that specifies the associated root certificate (Figure 3):

Figure 3.  Set-VPNAuthProtocol secures our VPN.
Please note, this script does not provide errors if the variable doesn't match a subject a certificate in the Trusted Root store. The Root Certificate field simply remains empty (e.g., Figure 2).
Step 3:  Restart the RRAS service.

Additional Thoughts:

Consider additional PowerShell safeguards for certificate authentication:
  • Define the server certificate sent to clients:
    Set-VpnAuthProtocol –CertificateAdvertised
  • Only accept certificates issued for client authentication:
    Set-VpnAuthProtocol –CertificateEKUsToAccept
Consider implementing both certificate and EAP authentication.  This may not be a good fit for all devices because of different types of clients.  However, if every client is Windows 10 we may be better off with SSTP.

Alternately, S2S VPNs can serve as a work-around for this public CA free-for-all.  We can assign specific client authentication certificates to individual S2S interfaces.  The system works but it creates administrative overhead.  I’ll write more about this in a future article.

Finally, it’s OK to implement both solutions:  Remove all public CAs from the Trusted Root Store; and only authenticate clients from our private CA (i.e., PowerShell).

That’s It!


Transfer SQL TempDB


How to transfer the TempDB.


MS SQL ran slow on 6Gb/s SAS hard drive (HHD).  Moved the user database (DB) to PCIe x4 (i.e., 31.52 Gb/s), MLC solid-state (SSD) storage -and it still runs slow!


Does the TempDB run on the old HHD drive or the new MLC SSD?  Consider how the TempDB can generate serious disk I/O.  Transfer the TempDB to the high-speed SSD as well.  N.B., this entire process gave new life to my old DPM2010 server.

  Step 1:  TSQL script to identify TempDB location:

Use master

name AS [LogicalName]
,physical_name AS [Location]
,state_desc AS [Status]
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
   TSQL output:

tempdev C:\Program Files\Microsoft DPM\SQL\MSSQL10.MSDPM2010\MSSQL\DATA\tempdb.mdf
templog C:\Program Files\Microsoft DPM\SQL\MSSQL10.MSDPM2010\MSSQL\DATA\templog.ldf

  Step 2:  TSQL script to move TempDB to new location.

USE master;

MODIFY FILE (NAME = tempdev, FILENAME = 'X:\SQL\Data\tempdb.mdf');

MODIFY FILE (NAME = templog, FILENAME = 'X:\SQL\Data\templog.ldf');

   TSQL output:

The file "tempdev" has been modified in the system catalog. The new path will be used the next time the database is started.
The file "templog" has been modified in the system catalog. The new path will be used the next time the database is started.

  Step 3:  Restart SQL services

  Step 4:  Verify Change - See Step 1.


SQL server runs quick with new storage.  Disk queue lengths, for all disks, are a thing of the past.  Individual results may vary based on load (duh).

That's It!


Harden RRAS IKEv2

How To:  

Harden Windows Server 2012R2 Routing and Remote Access (RRAS) VPN server.  Implement strong IKEv2 VPN cryptography:
• Diffe-Hellman Group (DH) 14 or DH Group 19
• Enable AES256 and SHA256 L2TP/IPsec and IKEv2 on Windows Server VPNs.

This simple method significantly improves security strength for Windows 2012 IPsec VPNs.


Windows RRAS server negotiates insecure IKEv2 and L2TP/IPsec cryptographic algorithms:

  • DH2-3DES-SHA1.   
Weak security strength risks data integrity and confidentiality.  IKE SA authenticates with RSA certificates.

This problem impacts all RRAS VPN clients:  Windows 10 phones, iPhones, Android, Cisco, Juniper and Sawn.  


Enable strong IPsec security algorithms in the Windows server registry:

  • IKEv2 DH14-AES256-SHA256

This (mostly) original approach is hands-down the easiest way to secure a Windows 2012 IKEv2 or L2TP/IPsec VPN.

Step 1:  Regedit:


Step 2:  Create new key:


Step 3:  Create new DWORDs (Table 1):

Table 1
IKEv2CustomPolicy DWORD Attributes

IntegrityMethod1Integrity check algorithm to be negotiated during MM SA negotiation [RFC4306].
EncryptionMethod4Encryption algorithm to be negotiated during MM SA negotiation [RFC4306].
CIPHER_AES_128 (0x2)
CIPHER_AES_256 (0x4)
CipherTransformConstant5Encryption algorithm to be negotiated during QM SA negotiation [RFC4306].
AuthTransformConstant1Specifies the hash algorithm to be negotiated during QM SA negotiation [RFC4306].
HMAC secret key authentication algorithm. SHA-1 (Secure Hash Algorithm) data integrity and data origin authentication algorithm. [RFC2404].
AUTH_CONFIG_HMAC_SHA_256_128 (0x2).
HMAC secret key authentication algorithm. SHA-256 data integrity and data origin authentication algorithm.
DHGroup3Type of Diffie-Hellman group used for Internet Key Exchange (IKE) key generation during MM SA negotiation [RFC4306].
DH_GROUP_2 (0x2)
DH_GROUP_14 (0x3)
DH_GROUP_2048 (0x3) - IKE for DH-14. Name change to match standard terminology
PfsGroup0Diffie-Hellman algorithm to be used for Quick Mode Perfect Forward Secrecy (PFS) [RFC4306].
PFS_NONE (0x0)
PFS_2 (0x2)
PFS_2048 (i.e., DH-14) (0x3)
PFS_MM (0x6) - Uses same DH as MM that contains this QM.
Note: DWORD values for IKEv2 Custom Policy Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\IKEv2CustomPolicy\
This method also supports stronger security (e.g., DH-EC and GCM).  See MSDN MS-RRASM for additional options.

Additional Thoughts:

Client Requirements:

VPN clients must support the same cryptography in order to connect.  Consider how Windows clients use DH2-3DES-SHA1 by default (yikes).  I'll provide instructions on how to update Windows 10, iPhones, and Android IPsec clients in an upcoming article.


PowerShell can implement stronger IKEv2 secuirty targets for both Windows 8.1 and 2012R2:

New-NetIPsecMainModeCryptoProposal -Encryption AES256127 -Hash SHA256 -KeyExchange DH19
Be warned, the process is challenging.  If you go this route don't test it out on production servers.  Also, the TechNet examples create new GPO policy specific to IKEv2.  It does not account for all the other firewall rules.  In other words, it creates a new firewall policy that only permits IKEv2 traffic -it's easy to get locked out without console access.  

The trick is to copy ALL firewalls rules and IPsec rules, crypto-sets, and IPsec rules (and anything else I haven't thought of) to the new GPO -all through PowerShell.  Alternately, use the GUI to copy the existing firewall settings to a separate firewall policy (i.e., separate from the PowerShell IKEv2 GPO).  Do not use the GPO GUI to edit the IKEv2 (i.e., PowerShell) firewall or you risk corrupting it.   You can then apply both GPOs to the VPN server.     

Also, we may be able to accomplish the same thing by saving the object to the local policy store.  Don't take my word on this because I haven't tried it yet.  So yeah, this is a bit more work but the benefits should provide solid security and greater interoperability.   

If anyone completes this script before I get around to it please forward me your work!  Either way, I'm sure it will be good material for another blog article.

That's it!  


Change Office Default Save Location


Office sets OneDrive as the default location during its installation.  This default location causes trouble for users who prefer to save to their local or network directories.  Word or Excel may prompt users for multiple authentication requests before they can save locally.


Change the default save location.
  1. Open any Microsoft Office 2016 program.
  2. Click on the File menu item.
  3. Click on Options.
  4.  Click on the Save tab located on the left menu.
  5. Toggle the check box field that reads “Save to computer by default”.  Click OK.

That's it!