Right clicking a folder and selecting properties is usually how you would see how large a folder is. Which is great, but if your folder size is HUGE (i.e. many terabytes) then this takes ages!
Solution
If you use PowerShell you can get the figure considerably quicker! Below I want to ge the size of E:\Shared;
While trying to fix another Azure AD Replication problem today I managed to delete one of the connectors (the one for the local ‘on-prem’ Active Directory). In an effort to ‘recreate’ it, I ran the ‘Microsoft Azure Active Directory Connect’ and went to ‘Customise the Synchronisation Options’. Unfortunately I got this error;
The forest {forest-name} cannot be added because the attribute used to uniquely identify your users in Azure AD (mS-DS-ConsistencyGuid) is already in use.
Thats not good! I was starting to get concerned.
Solution
There was, (on the old DirSync,) an install flag that would skip this step, would it still work? Yes it does, this time the wizard will complete, recreate the connector correctly and everything will work without any carnage! So what’s the command? See Below;
[box]
cd "C:\Program Files\Microsoft Azure Active Directory Connect"
AzureADConnect.exe /SkipLdapSearch
[/box]
By the time I checked the Synchronisation service, everything has burst back into life, and all was well.
Related Articles, References, Credits, or External Links
I was asked to setup a VPN to help out a colleague this week. When I had a look, one end turned out to be an Edge Gateway, I wasn’t that concerned, I’d done similar things in my prior role, I just didn’t have access to the vCloud or VMware at this datacenter.
Depite my best efforts on the ASA, the tunnel refused to come up, it took a little looking ‘under the covers’ to accurately diagnose the problem. But to save you my pain, I’ll post the setup of both ends so yours will be a little less stressful.
VMware Edge Gateway VPN Setup
Locate the Edge Gateway in vCloud Director > VPN > Create new VPN > Tick ‘Enable This VPN‘ configuration > Set the local and remote networks > Local ID is the local public IP of the Edge Gateway > Remote ID is the pubic IP of the Cisco ASA > Set the encryption protocol as AES256 > Copy the pre-shared-key (Warning: some browsers wont select all of the key, and you will end up characters short, make sure you have it all!) > OK.
On the ‘Firewall’ Tab allow all traffic TO and FROM the remote subnet, (behind the Cisco ASA).
Note: There no need to make a NAT Exemption.
Cisco ASA VPN Setup (For Edge Gateway)
Note: The version of Edge Gateway I was using, was using (once AES256 is selected)
IKE Version: 1
Encryption:AES-256
Hashing: SHA
Diffie Hellman: Group 2
Perfect Forward Secrecy: Enabled (group 2)
I’m aware that newer Edge Gateways support IKEv2 but debugging the incoming requests told me mine was using IKEv1.
You DO NOT have any existing VPNs configured, (if you do, change the name of the CRYPTO-MAP (above) to match the name of your cryptomap and use a higher number, e.g. ‘outside_map 2‘).
Troubleshooting Edge Gateway End of the VPN
You need access to the underlying VMware infrastructure > Select Networking and Security > Locate the NSX Edge > VPN > IPsec VPN > Show IPsec Statistics > Here you can see some meaningful error massages if theres a problem.
Troubleshooting Cisco ASA End of the VPN
I’ve covered this to death in the past, so rather than reinvent the wheel;
I did a Duo run through a few weeks ago, and to be honest their documentation is usually pretty good. I was spinning this up as a PoC for a client so I thought I’d put my take on the procedure here.
ADFS Duo Pre-Requisites
I already have a Duo Authentication Proxy server setup and my users are enrolled, you will need to set this up first. See the following article;
Log into the the Duo Admin Portal > Applications > Protect an Application > Search for and select Microsoft ADFS > Protect This Application.
Copy the Integration Key, Secret Key and the API hostname to notepad.
Download the Duo AD FA MFA Adapter on your ‘first‘ ADFS server. Enter the information you copied to Notepad, (above). Tick ‘Bypass Duo Authentication when offline’, and because my users are logging on with their Office 365 UPNs, I’m also ticking ‘Use UPN username format’ (SEE USERNAME NORMALISATION NOTE BELOW.)
Note: I only have one ADFS server, if you have an ADFS Server farm you will need to install each one with the SAME shared session key, you can generate one of these yourself in PowerShell with the following commands;
I only have one, so I’ll simply ‘Generate new session key‘ > Finish the install wizard.
Note: If one has already been deployed, and you don’t know the key, go to the ADFS server on which it’s working, and look in the following registry key.
USERNAME NORMALISATION: Because I’m logging users on with UPNs (first-name.last-name.domain-name.com) Back in the Duo Portal under protected applications Microsoft ADFS > Set username normalisation to ‘None” > Scroll down and save the change.
Server 2019 Only: I’m deploying on Server 2019 so I also need to execute the following Powershell command, you will need to enter YOUR API Hostname (you copied above).
Tick ‘Duo Authentication for AD FS {version}’ > Apply > OK.
Relying Party Trust > Here I have my Office 365 trust, yours may be for something else! Edit Access Control Policy.
Click ‘Use Access Control Policy’ > The one I want is ‘Permit Everyone and Require MFA for Specific Group‘. This way I can select who gets 2FA challenged, and I can migrate users slowly into this group once I know they are enrolled, (also I use the same group to Sync the users to Duo to make things simple). Change the <parameter> and locate you domain security group.
Now when the users connect to ADFS, after they logon, they are challenged to provide 2FA authentication.
like so;
Related Articles, References, Credits, or External Links
If you have something boring/repetitive to do then Powershell is your friend! I needed to do this for a client that’s replacing their Office365/Azure AD MFA (Multi Factor Authentication) with Duo.
Solution
Connect to your Microsoft Services Online, i.e. Office365/Azure, using your administrative credentials with the following command;
[box]
Connect-MsolService
[/box]
Then (Note: I’ve got more than 1000 users so I need to add the MaxResults switch).
Yesterday I wrote a post about Deploying a ‘Mapped’ Drive to a couple of users using Group Policy. This received a comment that was basically ‘Why not simply use Client Targeting?’ To be fair that’s a good point, I was using a Group Policy Preference and they can be specifically targeted. So here’s how to do that.
Solution
If you do not already have one, create a group for your users.
Add the users, (as appropriate).
On a Domain Controller > Administrative Groups > Locate the OU that contains your users (Note: if your users are in multiple OU’s, then after you have created the policy simply ‘Link‘ it to the applicable OUs).
Edit the policy.
User Configuration > Preferences > Windows Settings > Drive Maps > New > Mapped Drive > Action = Create > Location = Set the UNC path to the mapped drive > Tick ‘reconnect’ > Label as ‘What you want the user to see it called’ > Select the drive letter you want.
Common tab > Select Item-level targeting > Targeting > New Item.
Security Group. (Look at all the other cool stuff you can specify to target this group policy preference!)
Cisco HSRP: Normally your client machines have one route off the network, (their default gateway). But what if that goes down? HSRP aims to solve this problem by assigning a ‘Virtual IP address’ to your default gateway (or default route). So that IP can be shared amongst two or more possible devices (routers, or layer 3 switches).
Above, we have a client 192.168.1.10 that has two possible routes off the network, (.254 and .253). We will setup a virtual IP of .250 and both routers can use that IP, (if they are the active gateway). Below is a brief overview of how to set it up.
Deploy Cisco HSRP
Setting up Cisco HSRP
1. On the first router (Router0), add the standby IP address (192.168.1.250) the ‘1’ denotes the standby group (a number from 0 to 4096). It comes up as standby, then after it has checked (via multicast address 224.0.0.2 on UDP port 1985). It finds no other live HSRP devices using that IP address so it becomes ‘Active’.
[box]
Router0>enable
Router0#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router0(config)#interface GigabitEthernet0/0
Router0(config-if)#standby 1 ip 192.168.1.250
Router0(config-if)#
%HSRP-6-STATECHANGE: GigabitEthernet0/0 Grp 1 state Speak -> Standby
%HSRP-6-STATECHANGE: GigabitEthernet0/0 Grp 1 state Standby -> Active
Router0(config-if)#
[/box]
2. Repeat this on the second Router, this one discovers the ‘Active’ router and sets itself up as ‘Standby’.
[box]
Router1>
Router1>enable
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface GigabitEthernet0/0
Router1(config-if)#standby 1 ip 192.168.1.250
Router1(config-if)#
%HSRP-6-STATECHANGE: GigabitEthernet0/0 Grp 1 state Speak -> Standby
Router1(config-if)#
[/box]
3. You can prove this by running show standby (or do show standby in configure terminal mode).
[box]
Router0
Router0#show standby
GigabitEthernet0/0 - Group 1 (version 2)
State is Active
8 state changes, last state change 00:02:02
Virtual IP address is 192.168.1.250
Active virtual MAC address is 0000.0C9F.F001
Local virtual MAC address is 0000.0C9F.F001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.055 secs
Preemption disabled
Active router is localStandby router is 192.168.1.253Priority 100 (default 100)
Group name is hsrp-Gig0/0-1 (default)
Router0#
Router1
Router1#show standby
GigabitEthernet0/0 - Group 1 (version 2)
State is Standby
3 state changes, last state change 00:10:44
Virtual IP address is 192.168.1.250
Active virtual MAC address is unknown
Local virtual MAC address is 0000.0C9F.F001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.125 secs
Preemption disabled
Active router is 192.168.1.254Standby router is localPriority 100 (default 100)
Group name is hsrp-Gig0/0-1 (default)
Router1#
[/box]
4. That is HSRP configured! However there are a few changes you might want to make, for example, what if one router had a 100MB leased line, and the other was a 2MBADSL line, you would want the fastest one to be in use, (as long as it was up). To achieve that, give the router with the fastest connection a higher priority (you may notice above, that by default the priority is 100). Be aware, even if a router has the highest priority, it wont ‘seize’ the virtual IP, it just sits and waits until it’s available. For our 100MB and 2MB example that’s not good. We would want Router1 to seize the virtual IP as soon as it can. To do that we need to set it to preempt. (Note: This process is called ‘launching a coup’).
5. At this point it’s important to say, that in our scenario we would also need to setup a virtual IP for the ‘other side’ of the routers (i.e their GigabitEthernet 0/1 interfaces), or the remote client (172.16.1.10) would not be able to return our ‘pings’ or get any traffic back to us. So lets setup a virtual HSRP address on that side as well. Notice I just use another standby group number.
Note: To work the remote host 172.16.1.10 will need its default gateway changing to the HSRP Virtual IP of 172.16.1.250.
[box]
Router0
Router0(config)#interface GigabitEthernet0/1
Router0(config-if)#standby 2 ip 172.16.1.250
Router0(config-if)#
Router1
Router1(config)#interface GigabitEthernet0/1
Router1(config-if)#standby 2 ip 172.16.1.250
Router1(config-if)#
[/box]
6. Finally we have set Router0 with the highest priority and set it to seize the virtual IP as soon as it can. But what if another interface on Router1 goes down? e.g. If the GigabitEthernet 0/1 interface were to go down, HSRP would not do anything because it’s tracking both the GigabitEthernet 0/0 interfaces, so communications would fail.
To solve the problem we need to tell it which interfaces to ‘Track’. In our example we need to track GigabitEthernet 0/1, if that goes down we need to give the virtual IP address to the standby ‘router’. This works because once we tell it to ‘track’ the GigabitEthernet 0/1 interface, if that were to fail it will DECREMEMT the routers priority by 10. So for Router0 its priority would drop to 95, this is five less than the default value of 100 (on Router1). But Remember, at the moment that fail-over would still fail, unless you allow Router1 to preempt and launch a coup.
7. We can see that by running a ‘show standby’ on Router0.
[box]
Router0#show standby
GigabitEthernet0/0 - Group 1 (version 2)
State is Active
7 state changes, last state change 00:00:31
Virtual IP address is 192.168.1.250
Active virtual MAC address is 0000.0C9F.F001
Local virtual MAC address is 0000.0C9F.F001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.81 secs
Preemption enabled
Active router is local
Standby router is 192.168.1.253, priority 115 (expires in 7 sec)
Priority 115 (configured 115)Track interface GigabitEthernet0/1 state Up decrement 10
Group name is hsrp-Gig0/0-1 (default)
GigabitEthernet0/1 - Group 2 (version 2)
State is Active
6 state changes, last state change 00:00:28
Virtual IP address is 172.16.1.250
Active virtual MAC address is 0000.0C9F.F002
Local virtual MAC address is 0000.0C9F.F002 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.81 secs
Preemption disabled
Active router is local
Standby router is 172.16.1.253
Priority 100 (default 100)
Group name is hsrp-Gig0/1-2 (default)
Router0#
[/box]
Related Articles, References, Credits, or External Links
On EE this morning someone asked how to map a drive to only two users, so that wherever they logged in, they got their mapped drive. Seemed like a good Idea for a post so here you go;
Solution
If you do not already have one, create a group for your users.
Add the users, (as appropriate).
On a Domain Controller > Administrative Groups > Locate the OU that contains your users (Note: if your users are in multiple OU’s, then after you have created the policy simply ‘Link‘ it to the applicable OUs).
Edit the policy.
User Configuration > Preferences > Windows Settings > Drive Maps > New > Mapped Drive > Action = Create > Location = Set the UNC path to the mapped drive > Tick ‘reconnect’ > Label as ‘What you want the user to see it called’ > Select the drive letter you want > Apply > OK > Close the policy editor.
With the policy selected > Delegation. > Advanced > Authenticated Users > REMOVE ‘Apply Group Policy’.
While trying to connect Outlook (2016) to an Office 365 email account;
We can’t connect you
It looks like we can’t connect you to one of our services the moment. Please try again later, or contact your helpdesk if the issue persists.
0xCAA70010
{ADFS-URL}
Solution
This was happening because my ADFS server was using a ‘self-signed’ certificate (i.e. not a purchased one). This should NEVER be done in a production environment, but this is my test network, (so I refuse to spend money on certificates for testing etc!)
I cured the problem by simply importing/trusting the CA Certificate from my internal Certificate Services CA server, (that issued the ADFS servers certificate).
If you see this on a production server, with a publicly signed certificate, check that the ‘problem’ client does not need a Windows Update, to update its trusted CA Certificates, or that your certificate simply hasn’t expired, and you ‘forgot’ to renew it. If so;
I had a client machine struggling to get an DHCP address, and when I looked in DHCP the scope it was full of this;
BAD_ADDRESS This address Is Already in Use
Solution
A tour of Google and forums is full of posts by people with this problem, and other than, ‘Oh I looked in the logs and fixed it’ (with no mention of what log, or where this log was), or ‘Yeah I used Wireshark and located a problem client‘, then no follow up on what they did, or scanned for. So I pretty much had to slog through and work it out for myself. I’ll detail each step I took below, most of which didn’t help, or sent me in the wrong direction, but for you that may be a better solution.
And I will give you enough information to at least be helpful!
Firstly Common Sense Check: If this has just happened what have you changed? Have you added any Wireless Controllers, or Access Points? Have you deployed any new Switches or Firewalls. In my case, it was my test network so it could have been happening for months!
The most frequent cause of this error is simply because someone has setup another DHCP server on the network. That will be easy to diagnose, simply ‘Stop’ your DHCP Server;
Then on a DHCP client, issue an ifconfig /release and ifconfig /renew, If it gets an IP address, issue an ifconfig /all and look for the IP of the DHCP server it’s using, that’s your culprit. However as you can see, mine didn’t get an IP address so this wasn’t my problem.
The next most popular suggestion is to enable ‘Conflict Detection‘, though in most places the information on where to find this, is incorrect, (as it’s been copied and pasted around the forums without actually checking it!) See below, you locate it on the properties of the Protocol not the Server > Advanced Tab > You are supposed to set it between 1 and 6 so I went for 5, (but after deleting all the BAD_ADDRESS entries, they were all back after 30 minutes or so, so this didn’t work for me either).
Look in the logs: Well they were useless also, DHCP creates a new log every day in C:\Windows\System32\Dhcp called ‘DHCPSrvLog-DAY.log’ as you can see it was not helpful.
At this point I put my networking head on, and ‘thought outside the box’, If DHCP is detecting these as BAD ADDRESSES, then they must be in the arp cache on the DHCP server right? Well look at this;
[box]
arp -a
[/box]
Well that’s encouraging, at least now I’ve got a suspect MAC address, lookup up that MAC address online, and it comes back as VMWare (which sent me off in the wrong direction, it was not a VMware virtual machine in my vSphere in the end). Ive got a decent Cisco Switch so I thought I’d see which interface it was connected to, (but it wasn’t there).
[box]
show mac address-table
[/box]
At this point I was still thinking it was a VMware virtual machine, so I used PowerCLI (Thats PowerShell for VMware), to query for that MAC address, but that revealed nothing.
So, my last hope was Wireshark, I fired it up on the DHCP server, and set the filter to;
[box]
bootp.option.type == 53
[/box]
Then I deleted all the BAD_ADDRESS entries, left Wireshark ‘sniffing’, and went for lunch. I returned to this (see below). Now 192,168,100,107 was one of the BAD_ADDRESS entries, and I did not know what it was. The other entries on there for 192.168.100.3 are understandable, (that’s my DHCP server!) So now I had a Layer 3 address to hunt.
When I RDP connected to it, I got prompted for a password, so now I know it’s a Windows box! I hunted all through my VMware virtual machines, it was not there. Just as an afterthought I remembered I have a Hyper-V server, could that be running a virtual machine? BOOM! There is a SCVMM server, I was using for some Zerto testing a couple of months ago! Turned it off, problem solved!
Hope you find your culprit quicker than I did!
Related Articles, References, Credits, or External Links
