Search This Blog

Monday, April 28, 2014

Install Driver Silently

This is once again an old trick, that unfortunately does not work for all drivers, but this might be the place to start.

When I need to install a driver silent, I always start with PNPUTIL.

http://technet.microsoft.com/en-us/library/ff800798.aspx

First step is to collect the files needed with the INF file in a folder as shown here for VMware SVGA 3D

image

Before installing the driver my Display adapter is Standard VGA Graphics Adapter:

image

Now lets install the driver with the command

pnputil –i –a vm3d.inf (or pnputil –i –a *.inf)

image

Now the driver is changed, this can of course easily be used in scripts.

image

Monday, April 21, 2014

Temporary license has expired

You might see this message when connecting to your published XenAPP desktop.

The remote session was disconnected because there are no Terminal Server License Servers available to provide a license.

image

In a production environment we will of cause have to take a closer look at the RDS License Server, but in a small lab environment running with temporary client licenses, this might be expected.

If we take a closer look at the XenApp server you can find the event id 1001:

The remote session could not be established from remote desktop client xxx because its temporary license has expired.

image

We now know that this is related to the use of temporary licenses and we can temporary fix it until next time the license expires.

On the client with the problem open regedit and locate the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing.

Then delete or rename this key and next time you start your published desktop it will recreate the key and a new Temporary CAL will be assigned on the server.

Also be aware that since we are dealing with a HKLM key you must be able to use elevated rights when deleting the key and when recreating the key!

image

Monday, April 14, 2014

Active Directory Schema Versions

In order to check your current Active Directory schema version we can use the attribute objectVersion.

The attribute objectVersion on the schema container object stores the schema version of the forest. This attribute is set during the creation of the first domain in a forest and is changed during schema upgrade after the schema is successfully upgraded to a newer version. In AD DS, to add a DC running a particular Windows Server version to an existing forest, the objectVersion of the forest's schema container must be greater than or equal to the value for that Windows Server version.

To do the check start adsiedit.msc and select Connect to.

clip_image001[14]

Then select Schema in Select a well known Naming Context:

clip_image001[12]

Expand the Schema node and select properties in the right side on CN=Schema,CN=Configuration,DC=xx,DC=xx (using right click)

clip_image001

Now find the attribute objectVersion

clip_image001[16]

The possible objectVersion values are listed in this table (so this example is taken from an Active Directory Schema with Windows 2012 version):

Version objectVersion
Windows Server 2000 13
Windows Server 2003 30
Windows Server 2003 R2 31
Windows Server 2008 44
Windows Server 2008 R2 47
Windows Server 2012 56
Windows Server 2012 R2 69

You will also be able to use DSQuery as shown here:

dsquery * cn=schema,cn=configuration,dc=xx,dc=xx -scope base -attr objectVersion

clip_image001[18]

And PowerShell:

Get-ADObject -Identity "cn=Schema,cn=Configuration,dc=xx,dc=xx" -Properties objectVersion

clip_image001[20]

Information about Lync Schema versions http://larslohmann.blogspot.dk/2012/08/lync-schema-version.html

Information about Exchange Schema versions: http://larslohmann.blogspot.dk/2012/07/exchange-schema-version.html

Monday, April 7, 2014

The trust relationship between this workstation and the primary domain failed

You might not be able to logon to your computer and Windows will sat that The trust relationship between this workstation and the primary domain failed.

image

Typical this will mean that the secure channel with the domain is broken, as explained in this post:

http://blogs.technet.com/b/asiasupp/archive/2007/01/18/typical-symptoms-when-secure-channel-is-broken.aspx

Nowadays we are able to use PowerShell on the failing workstation to fix the issue.

Logon to the workstation with a local administrative user or disconnect the network and logon with a domain administrative user that has previously been logged on to this workstation. By disconnecting the network we can sign in with cached credentials without checking the trust relationship.

When logged on remember to connect the network again and start PowerShell as administrator.

image

Now use this PowerShell command replacing DC with your domain controller and domain\user with a valid domain and administrative user:

Reset-ComputerMachinePassword -Server DC –Credential domain\user

image

You will be prompted for the password:

image

After the change sign off and try to sign in again, now the trust relationship should work.

http://technet.microsoft.com/en-us/library/hh849751.aspx

But it will only work if you use PowerShell version 3.0 Windows Management Framework 3.0