Wireless Projection / Miracast option disappears from Microsoft Surface Pro 3 / Windows 8.1 after joining a Active Directory Domain

We recently deployed some Microsoft Surface Pro 3s (love these devices) for our Executive team along with some new equipment in meeting / board rooms with Wireless Display capabilities. During testing with my personal SP3 (not domain joined) the wireless display worked a treat, so I expected it to work fine on the ones we would be deploying.

After about a week, one of the managers shot me an e-mail saying he couldn’t see the option for wireless display, that night he had performed a reset of the device, came in and had the option, but once we joined it back to the domain, it disappeared. I started digging around Group Policy to see what was causing it to disappear and found that these devices were getting an old “XP” based Wireless Network Policy.  I upgraded the policy which then gave us some extra options, including allowing / disallowing Wi-Fi Direct.upgraded policy

Computer Configuration > Policies > Windows Settings >Security Settings > Wireless Network (IEEE 802.11) Policies

The setting Don’t allow Wi-Fi Direct groups which needs to be disabled can be found under the “Network Permissions” tab. From what I can see, any Wireless policy configured for XP doesn’t have this option and a machine will simply disallow it.

How is Miracast or WiDi related to Wi-Fi Direct?  Well basically Wi-Fi Direct allows devices to connect directly to each other, without the need for a Wi-Fi AP, which is exactly what your surface is doing when attempting to stream the display straight to a TV / Projector.

Once we had this option turned off, ran a gpupdate on the machine and viola, wireless display showed up and began working.

 

How to protect all existing Organizational Units (OUs) in your Active Directory domain from Accidental Deletion by using PowerShell

We recently took on a new hire, although I was confident in their ability in managing Active Directory I wanted to take an extra step in protecting Organizational units from deletion.  I was sure that I could do this quickly using PowerShell instead of right-clicking each of our 80 odd OUs and going into their properties.

To do this we need to open the Active Directory Module for Windows PowerShell as an administrator.  Since I began in my System Admin role, I was creating OUs that were protected, so I only really needed to do this to the ones that were already here.  So first we need to work out what OUs are not protected from this list using PowerShell I can easily pipe it into the command we need to issue to protect the OUs

The first command below will output a list of all OUs currently not protected.

Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | 
where {$_.ProtectedFromAccidentalDeletion -eq $false} | ft

This command does the above but also sets the ProtectedFromAccidtenalDeletion to True.

Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | 
where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit 
-ProtectedFromAccidentalDeletion $true

Once this command is issued, all the Organizational Units in our Active Directory have become protected and should help prevent you from getting into those sticky situations where someone (could be you) from deleting one by mistake.

Fixing KDC Authentication Problems when upgrading your domain and forest functional level from 2003 to 2008 R2

We recently upgraded our Domain and Forest Functional Level from 2003 to 2008 R2, after a day or so I started having problems connecting to a number of 2008 R2 Hyper-V Virtual Machines. When attempting to connect I would receive the following error:
An Authentication Error Has Occurred. The Encryption Type Requested Is not supported by the KDC
At around the same time we also had one of our Exchange 2010 Transport Servers stop servicing clients, when I attempted to open the Exchange management console on the local server console ended with a HTTP server error status 500 and “Kerberos” authentication failed. So I decided to take a look through the event viewer to see what was up.

As part of Exchange there is an Active Directory Topology Service which will scan your environment for Active Directory Servers every 15 minutes or so, all of the exchange services rely on this service (if you ever have to restart all exchange services, simply restart the AD Topology Service). In the application event log I noticed the following error message:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=xxxx). Topology discovery failed, error 0×80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message))….
There were also issues with the Exchange STORE service with the following two events:
Process STORE.EXE (PID=xxxx). All Global Catalog Servers in forest DC=xxx,DC=xx,DC=xx are not responding.
Process STORE.EXE (PID=xxxx). All Domain Controller Servers in use are not responding

The rather simple resolution to all this trouble is simply to restart the KERBEROS DISTRIBUTION KEY or KDC service on all Domain controllers. While simply restarting the Service will solve the problem, you’re probably better off just doing a proper restart after upgrading your functional levels, only from 2003 to 2008 / 2008 R2.

Allowing anonymous relay on Exchange 2007/2010 on connectors for programs to send via SMTP using your Mail servers and how to secure it for internal use only.

I was recently helping out a colleague at another school as they were having difficulty in a specialised application sending e-mails to external addresses.  After a bit of investigating we found that the send connector configured for internet e-mail wasn’t allowing anonymous connections to it (which is dangerous) but since this particular application didn’t allow us to specify authentication details we were forced to enable anonymous relay for this connector.

I will first show you the PowerShell command that we used to grant the anonymous permissions for the connector that you specify:

Get-ReceiveConnector “Default SBSSERVER” |
Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON”
-ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Now the above is really one command getting piped into another, so first of all we are specifying a particular receive connector, in this case Default SBSSERVER (change this to reflect the connector you want to modify).  We are then simply giving rights to anonymous logons (anyone) telling exchange to accept any recipient.

Now as for securing this connector, I would strongly suggest creating a separate one for this particular application (for example Sales App Connector).  We then add incoming IP restrictions, by editing the properties of the receive connector and adding entries to Receive mail from remote servers that have these IP addresses using either specific IP addresses or IP ranges in CIDR notation (so 10.1.0.0/16).

And there you have it, allowing anonymous connections / relay for internal applications to use.

Getting a list of users in Active Directory as well as their Logon Script using dsquery and dsget

So I’m preparing on doing a clean-up of our NETLOGON/SYSVOL folder containing about 50 or so different logon scripts (plenty of which I know are no longer used).  I wanted to create a list of all of our active directory users along with what logon script they were assigned (I could then feed this list into excel and play around).  I realised that I could get this information using dsquery, but how exactly do I build a query to get a logon script.  The following command is what I used, I will then break it down for a better understanding.

dsquery user -name * | dsget user -display -loscr > C:\users_script.txt

So we’ve got our dsquery, which is really looking for AD object types of user with a name of anything, so basically ALL user objects in Active Directory (you can also optionally specify a limit using -limit).  We then pass on this list to dsget which will use this information to obtain the objects’ display name (with -display) and logon script (-loscr).  I am then simply piping the output to a text file.

So that is a quick and easy way of getting a list of all users in AD along with their logon script.

Deploying printers via Group Policy and getting them pushed out the right way as well as solving driver installation issues (0x80070bcb Specified printer driver was not found and needs to be downloaded)

So we recently upgraded our printing infrastructure with a whole new lot of printers and software (along with a shiny new version of PaperCut MF) and have implemented a global queue or better known as Follow Me Printing.  So how do we go about pushing out all the new global printers to our users.  Well along with the 50 other projects we have on the go, one of them is a clean up of our group policy, so after removing around 15 GPOs related to our old printers I got to work.

So for starters I’ve created a GPO which will contain all of our Follow Me Printing settings, including deploying the PaperCut Client and Global Queue Printers. In our environment we have a mix of Windows XP, Windows Vista and Windows 7 which will all handle printers being deployed via Group Policy differently (Microsoft make things so easy, don’t they).  For XP, things are simple, simply add the printer to be deployed either by user or computer preference under control panel > printers. For Vista and 7 however this is where it gets tricky.  If you are using a driver which has been loaded on the machine before, the printer will deploy, otherwise you will receive an error in the event log such as the following:

The user 'Printer Name Here' preference item in the 'Group Policy Object
{GUID-GOES-HERE}' Group Policy object did not apply because it failed with
error code '0x80070bcb The specified printer driver was not found on the system
and needs to be downloaded.' This error was suppressed.

This basically means that the client couldn’t download the driver, but the real reason is because of UAC and the computer not requesting permission to install a driver. Thankfully there is a Policy that we can enable that will allow us to set the permission requirements during printer driver installation.

Using the Point and Print Restrictions Policy we can enable printer driver installation without it getting hassled by UAC. Under Windows Vista it is a User Policy and on Windows 7 it is a Computer Policy (I have both enabled for good measure). So enable toe Point and Print Restrictions Policy and change the following options:

  • When installing drivers for a new connection: Do not show warning or elevation prompt
  • When updating drivers for an existing connection: Show warning only

Once we have configured the Point and Print Restrictions Policy printers will download and install on any client computer that the Object is targeting.

Hope that helps a few people out when setting up and configuring their Group Policy Printer Distribution, any queries please comment.

Applying inherit rights (inheritable) for permissions to a large number of Active Directory objects

I was recently involved in a project to help secure a School’s Active Directory environment.  After sitting down and planning what we wanted to achieve in terms of account security we went to work.  After setting up all of the IT based security groups and assigning and delegating the appropriate rights and permissions we found that somethings wern’t working as they should.  The permissions gave us the rights to do what we needed on the Student user objects but not on the staff.  After taking a quick look we found that the majority of Staff didn’t have their inherit permissions from parent ticked, which prevented the delegation from flowing through to these user objects.

Looking at PowerShell there are Get-ADUser and Set-ADUser which allow us to get and set certain properties on user objects but still didn’t allow us to set inherit rights on objects.  I then happened to stumble upon a management pack of PowerShell scripts from Quest Software which are available from this link. The pack contains some useful scripts which extend on the original Microsoft provided scripts.  The pack also contains a PowerShell cmdlet dealing specifically with Object Security which is what we are after. So I went ahead and downloaded the 64 bit version to one of the domain controllers (after testing it out myself) and worked out we needed to filter for users who didn’t have the inherit permissions enable. The following is a snippet which will list all of the users in your AD environment with inherit permissions disabled (watch the word wrap):

Get-QADUser -SizeLimit 0 |
Where-Object {$_.DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected}

If you are after a particular Organizational Unit simply replace -SizeLimit 0 with -SearchRoot ‘Distinguished name of OU’.

Now we are able to find the users, but what about setting the inherit right.  Using the ObjectSecurity cmdlet we can now set the Inheritance flag. So the following is the complete command to run on l (again, watch the word wrap):

get-QADUser -SearchRoot 'Distinguished Name of OU' |
Where-Object {$_.DirectoryEntry.PSBase.ObjectSecurity.AreAccessRulesProtected} |
Set-QADObjectSecurity -UnLockInheritance

After running that cmdlet on the offending User Objects, we were then able to successfully do what the security groups allowed us to do. I still need to go back and check out what else the pack from Quest can do as I looked quite interesting so I will be sure to blog about my findings.

Setting up an SPN and fixing the cannot verify the service principal name error when installing ForeFront Endpoint Protection

We are currently in the process of trailing Forefront Endpoint Security along with our SCCM Deployment.  So after a few weeks of tweaking we have got our systems center deployment to a level where we are happy with it, it was time to begin installing and testing Forefront.

After beginning our installing and answering a few questions the setup begins to validate some per-requisites. Apart from having reporting services installed and configured on a SQL Server you also need to have the service account for SQL Server to be publishing its existence via a Service Principal Name or SPN. If the account doesn’t have a valid SPN entry then you will receive the following message during the per-requisites check of the Forefront setup.

Setup cannot verify the service principal name (SPN) for this account.
Ensure that there is a single valid SPN entry for this account in the
Active Directory Domain Services.

So how do we go about adding an SPN entry. We will use sqlservice as our user account. We can either do this via ADSIedit or the command prompt. Open up an elevated command prompt and enter the following command:

setspn -a MSSQLSvc/sqlserver.fqdn domain\sqlservice

with MSSQLSvc being the protocol, sqlserver the name of the Server hosting SQL Services along with your fully qualified domain name and finally the account you wish to add the SPN entry for. To check that you have successfully added the spn you can do the following:

setspn -l domain\sqlservice

which will list the account along with SPNs being advertised for that particular account.

The quicker way would be to run ADSIedit, find the account you wish to add the SPN for, right click and go properties and then under the attribute editor. From there navigate down the list until you find servicePrincipalName and click edit. You can then enter the SPN in the same format as above, which is:

MSSQLSvc/sqlserver.fqdn

And there you have it, you can continue to install Forefront without any issues so long as you meet the other requirements of the setup.

Assigning resources via logon script based on computer names.

We’ve recently been having an issue where printers being deployed via group policy haven’t been deploying, or are deploying but not being set to default.  So after some investigation, the easiest thing to do would be to write a Visual basic script to ease the deployment of printers throughout our environment. Luckily for us we have naming conventions and machines are usually called 2011uname or 2014uname, based on a student’s final year.

You can use this script for all sorts of things, from allocating printers and mapping network drives. To increase or decrease the amount of characters that the script looks at simply modify the strLength (Define String Check Length) variable at the beginning of the script.

'Actions based on Computer name for logon scripts
'Define String Check Length
strLength = "4"

'Get the computer name
Set WSHNetwork = CreateObject("WScript.Network")
strComputer = WSHNetwork.ComputerName

'Select year level by ending year
Select Case Left(strComputer,strLength)
    Case "2011"
        msgbox "year 12"
    Case "2012"
        msgbox "year 11"
    Case "2013"
        msgbox "year 10"
End Select

The script will print out a message box, but within the case you can specify what ever action you want. Hope that helps someone out.