Disclaimer: Editing the AD schema should not be taken lightly. Changes can be irreversible. Do this at your own risk!

Open the Active Directory Schema

First, Open the Schema Management Snap-in. By default, Microsoft wants to keep you out of the Schema, so you may need to enable it by registering the Schema Management DLL. To do this, run this command from a command prompt:

regsvr32 schmmgmt.dll

Next, Open MMC and add a new Snap-In. You’ll now see “Active Directory Schema” in the list. Select it, click add and click OK.

Create the Custom Attribute

Expand Active Directory Schema, Right click on Attributes and click Create Attribute

You will get a warning instructing you of the dangers of modifying the schema. If you are ready to proceed, click Continue.

The Create New Attribute form will appear. Enter the name of the custom attribute in the Common Name field. In my case, it’s FavoriteBeer. Avoid special characters and spaces.

The LDAP Display Name should automatically be created with first letter lowercase. (This follows the camelCase like standard for most of other attributes) Modify it if needed, but it’s probably best left alone.

The Unique X500 Object ID requires a little extra work. (Why don’t they just have a “generate OID” button). We have to generate our own unique OID. This OID must be in the correct format and must also contain the correct prefix. To make this easy, open up a PowerShell window and copy\paste the following commands (Tip: You can paste the whole block at once):

 $Prefix="1.2.840.113556.1.8000.2554" 
 $GUID=[System.Guid]::NewGuid().ToString() 
 $Parts=@() 
 $Parts+=[UInt64]::Parse($guid.SubString(0,4),"AllowHexSpecifier") 
 $Parts+=[UInt64]::Parse($guid.SubString(4,4),"AllowHexSpecifier") 
 $Parts+=[UInt64]::Parse($guid.SubString(9,4),"AllowHexSpecifier") 
 $Parts+=[UInt64]::Parse($guid.SubString(14,4),"AllowHexSpecifier") 
 $Parts+=[UInt64]::Parse($guid.SubString(19,4),"AllowHexSpecifier") 
 $Parts+=[UInt64]::Parse($guid.SubString(24,6),"AllowHexSpecifier") 
 $Parts+=[UInt64]::Parse($guid.SubString(30,6),"AllowHexSpecifier") 
 $OID=[String]::Format("{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}",$prefix,$Parts[0],$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6]) 
 $oid

Here is an example of what this looks like. The OID is the highlighted text below. Copy and paste this in the X500 Object ID field. This is example output. Do not use the same OID that I got. Run the commands to get your own.

Feel free to give your new attribute a useful Description.

Next is Syntax. This is the data type of your new attribute. Since I need to store names of drinks that may contain letters and numbers, I selected Unicode String for alpha-numeric data. I left the Minimum and Maximum range blank. Here’s what mine looks like:

When finished, double check everything (Remember this can’t be undone). Then click OK.

You have now created a new Active Directory Custom Attribute. Next step is to bind it to the User Class.

Bind the Attribute to the the User Class

To do this, Click on Classes, then find and double click on the User Class:

Click the Attributes tab, then click Add and find your new attribute and click OK. Your attribute will be added to the Optional attributes. Click OK to save and close the User Class Properties.

That’s it. You can close the Schema Management snap-in.

Test it

You can now modify this like any other user attribute. Open Active Directory Users and Computers (with Advanced Features enabled) and go to the Attribute Editor tab.

You can also query and set this new custom attribute via PowerShell:

-Carl

The post How to: Create a custom attribute in Active Directory appeared first on CarlStanley.com.

Problem: Some users trying to connect to VPN using FortiClient receive the error “Connection Error!” This error appears with no apparent pattern in OS or FortiClient version.

This error on its own is not helpful. For more detail export the FortiClient logs and open fortiagent.log:

20210524 13:07:34.070 [sslvpn:INFO] unknown:0 try to get cookie for the first time
20210524 13:07:35.084 [sslvpn:EROR] unknown:0 no SVPNCOOKIE found
20210524 13:07:35.085 [sslvpn:EROR] libsslvpn:587 Failed to login to fortigate : -112
20210524 13:07:35.085 [fctgui:EROR] FCTVpnConnection:1704 -112 -
20210524 13:07:35.085 [fctgui:INFO] FCTVpnConnection:1760 failure happens so terminate this vpn connection

“Failed to login to fortigate : -112” was a consistent error on the non-working clients. I also noted codes -111 and -113 on a couple machines. Most of my research into this error indicates that it can be resolved by trying different versions of the client. Try it, it may work for you. But for me I tried several different versions with no luck. I had to keep digging.

In my case this error is caused by how we used AD to provision VPN. We use nested security groups and gave the parent group VPN access. Normally this is a good practice as it makes management easy but the FortiGate didn’t like it. The result was that some users worked just fine while others didn’t. The ones who did work were direct members of the group.

How to fix: You could change your AD group membership and add people directly, but if you have a lot of users that’s not ideal. Instead, modify the VPN User Group on the FortiGate so that the nested AD groups are specified directly in the Remote Groups section. You can specify multiple groups.

The post How to fix: FortiClient Connection Error -112 appeared first on CarlStanley.com.

First off, PLEASE don’t take these as a negative view toward the product. That is not the intent here.  These are simply some things I have learned that I feel should be shared.   Simplivity has become the fastest growing infrastructure company to achieve a valuation of over $1 Billion, EVER.   And I really am blown away by their product.  There is still no better or cheaper way to give yourself a hyper-converged infrastructure. I will leave all that for a more thorough review later.  But based on my experience, these are things you need to know if you’re thinking making the plunge in to Simplivity.

–Update:
I replaced an item on the list regarding advertised usable memory.  Simplivity has fixed this.

1. Use the Simplivity tab in the vSphere client for correct datastore usage stats. The hosts see the raw capacity of the disks, not the capacity of the datastore.  This actually makes sense considering the host is also a node in the datastore, but will cause some initial confusion.
2. The OmniCubes CAN be put in to maintenance mode, but… If vMotion and DRS are enabled, the VMs WILL evacuate.  All except for the OVC.  You MUST shut down the OVC VM prior to entering maintenance mode.  It will yell at you for doing so,  warning that you shouldn’t shut it down, but that’s the only way.
3. The vCenter appliance is NOT supported.  This is probably to be expected with all their customizations.  There are APIs missing from the appliance that Simplivity needs.
4. vCenter MUST be run outside of the OmniCube Federation.  The shared storage requires a witness or the Arbiter.  And because of SSO, you might want to also run your domain controller outside of the federation.
5. Do not install vCenter using the Simple Install.  Take the time and install it correctly.  A simple install will prevent the use of Linked Mode.
6. Understand the difference between a VMware Clone and a Simplivity Clone. With a VMware clone, VMware is copying the files, while Simplivity simply modifies the metadata for the data blocks.  The VMware clone is still your only way to clone to other (non-omnicube) datastores and your only way to customize during the clone.
7. You don’t need a 10Gb switch if you only have two OmniCubes.  You can directly connect two cubes at 10Gb.
8. You must use the vSphere thick client to manage the Simplivity stuff.   Those of you who want to use the web client exclusively like VMware recommends, can’t.  The Simplivity plugin only works with the thick client.  This hasn’t changed in vSphere 6.0 though they say it’s coming.  
9. Come up with a plan to back up your data OFF of the federation. Simplivity calls what they have “backups.”  Yes you can back up your data and restore it if needed.  All it’s doing is adding a little more meta data to those de-duped bits.  And it backs it up to itself.  Not so cool if your entire federation goes up in smoke or those deduped bits get corrupted.  This can be great in larger geographically separated federations. Then it’s awesome.   But even then think of it as more of a belt and suspenders approach.  Use your usual backup tools, Veeam or CLI scripts to get that data off the OmniCubes.
10. Upgrades…  They still haven’t refined their upgrade process.  Upgrading from vSphere 5.1 to 5.5 was a lengthy process. Each OmniCube (we upgraded two) had to be manually upgraded by a Simplivity technician.  Even simple patches work the same way. For larger environments this would dissuade people from applying updates.  Lets hope some Heart Bleed style exploit doesn’t need to be patched in a hurry.  Though they tell me that with more than two cubes this process is a little faster. Indications are that future updates wont be any different.  The good news is that you can still migrate VMs to another cube during these upgrades and thus no VM downtime is required.  I fully expect that Simplivity will continue to improve in this area. With the explosive growth they are seeing, this kind of update \ patch model is not scalable.

The post Top 10 things all new Simplivity admins must know appeared first on CarlStanley.com.

Open up a Terminal window and enter the following command (choose the correct OS) to flush the DNS cache. Enter your password when prompted.

MacOS 11 – Big Sur

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Mac OS X 10.7, 10.8 & 10.9 & 10.10

sudo killall -hup mDNSResponder

Mac OS X 10.6

sudo dscacheutil -flushcache

The post How to flush the DNS cache on Mac OS X appeared first on CarlStanley.com.