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.

image

Then select Schema in Select a well known Naming Context:

image

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

image

Now find the attribute objectVersion

image

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

image

And PowerShell:

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

image

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

Monday, March 31, 2014

Identify weather SCCM 2012 R2 CU1 has been installed

Cumulative Update 1 for System Center Configuration Manager 2012 R2 has been released http://support.microsoft.com/kb/2938441

So once again it’s time to take a closer look at the version changes, this time for R2.

After upgrading to System Center Configuration Manager 2012 R2 CU1, you will be able to identify the update as shown here.

First let us take a look at the console, after the update the console reports version 5.0.7958.1203

image

The console reported version 5.0.7958.1000 before updating which is 2012 R2 RTM.

image

The Console update is also listed in Control Panel as an Installed Update.

image

The site will still report version 5.00.7958.1000 after the update.

image

In order to check if the update has been applied we must look in the registry.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Setup\CULevel

CULevel reports 1 after CU1 has been applied.

image

Before updating CULevel reported 0 because no Cumulative Update was installed.

image

This update is also visible under Installed Updates in Control Panel.

image

The client will report 5.00.7958.1203 after the client has been updated.

image

With these components updated:

image

Before updating the client reported 5.00.7958.1000 for 2012 R2 RTM client.

image

CU1 also includes a update for SCEP.

Which means that scepinstall.exe file in the ConfigMgr install folder “.\Program Files\Configuration Manager\Client” will be updated to version 4.5.0216.0

image

Before updating the version was 4.4.0304.0 which is the version from 2012 R2 RTM.

image

And finally as reported by the client after update 4.5.216.0.

image

The SCEP update will also be available from Microsoft Update according to the article: http://blogs.technet.com/b/configmgrteam/archive/2014/03/27/anti-malware-platform-updates-for-endpoint-protection-will-be-released-to-mu.aspx

System Center 2012 R2 Cumulative Update 1 also includes quite a lot of changes to PowerShell support for Config Manager http://support.microsoft.com/kb/2932274

Monday, March 24, 2014

DotNet 1.1 installation on Windows 7

This post is just in case should I ever need this again, yes I know it’s very old stuff Smile

To create an administrative installation point for .Net 1.1 with SP1 and hotfix, follow this:

 

Commands executed:

image

 

DotNet.Tmp folder after all files is downloaded and extracted:

image

 

  • Create the administrative installation folder with the command c:\DotNet.Tmp\dotnetfx.exe /c:"msiexec.exe /a netfx.msi TARGETDIR=c:\DotNet"
  • Patch the installation folder with SP1 msiexec.exe /a c:\dotnet\netfx.msi /p c:\dotnet.tmp\sp1.msp
  • Patch the installation folder with the hotfix msiexec.exe /a c:\dotnet\netfx.msi /p c:\dotnet.tmp\NDP1.1sp1-KB979906-X86.msp

 

Installation commands executed

image

Now install DotNet 1.1 with the command msiexec /i C:\DotNet\netfx.msi /quiet /norestart

If you just start the MSI on Windows 7 you will see this warning:

image

The warning can be bypassed if you set this value in the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags]
"{11F1F8EE-7E7F-4F1D-BE93-B4D310F0760A}"=dword:00000004

image

The installation will also add a RunOnce action, and you might want to remove the entry.

image

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce]
"NetFxUpdate_v1.1.4322"=-

 

Settings and installation in a vbscript:

Set oShell = CreateObject("WScript.Shell")
oShell.Regwrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\{11F1F8EE-7E7F-4F1D-BE93-B4D310F0760A}", 4 ,"REG_DWORD"

RunCommand = "cmd /c start /wait msiexec /i netfx.msi /quiet /norestart"
oShell.run RunCommand,0,TRUE

oShell.Regdelete "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce\NetFxUpdate_v1.1.4322"