Windows Terminal Services Logon “Access Denied”

I would like to describe resolution of the problem with Terminal Services. When you are using Terminal Services in conjunction with License Server on separate machine, you may experience following symptoms:

  • During the Logon Process, user receives the message “Access denied.”. It is shown instead logon screen, just after the “Welcome” message.
  • Within application and system event logs, there is no related error messages.
  • Within the TerminalServices-LocalSessionManager event log, there is following message correlated with user logon attempt: “Session X has been disconnected, reason code 12”, where X means number of logon session granted to user logon try by Session manager.
  • This problem you may experience on Windows 2008 R2 as well on 2012 (R2).
  • GPO policy update failure often occurs simultaneously.

Temporary solution to this problem may be modifying the following registry entry:
[cc lang=”Text”]HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\
IgnoreRegUserConfigErrors (DWORD) = 1
After addition of this registry value you need to reboot affected server.

After mitigation of poor user experience, you can peacefully start real diagnosis, what is wrong in your environment. In one of the cases, the real issue was mistake in windows firewall configuration of domain controlers, what was applied by GPO. In affecting GPO, there was rule denying “SMB over TCP” traffic.
It may be something different in your case, but always it must be something connect with domain controllers.


Failover Cluster Generic Script Resource Failed 0x80070009

Hi All,

I have found interesting behavior of Failover Clustering feature in Windows 2012 R2. Message from console and logs in this situation is quite Add to dictionary.
When you have done Generic Script Resource configuration, as described in this Microsoft Product Team Blog , you can find your resource down and following status message: [cc lang=”Text”]The storage control block is invalid.[/cc] I have shown that on this screenshot:
Status zasobu klastrowego
When we display the extended error message, we find out, that error code is [cc lang=”Text”]0x80070009[/cc]
Rozszerzona informacja o błędzie
Similar Entry we can find in Cluster Event Log:
Log systemowy klastra

In this situation we should verify if our script is not returning 0x9 value from any entry point function. When we assured that, this error tells us we have made syntax error in Visual Basic script and in the result cluster resources manager was unable to compile and execute that script.

That is why checking script (every, not only Visual Basic!) is general good practise. We can verify Visual Basic Script Behawior by running the script from command line. This can be done with following command:
[cc lang=”Text”]cscript.exe C:\pełna\ścieżka\do\pliku.vbs[/cc]
Correctly written script should write to console completelly nothing except VB host banner because Generic Script Resource should contain only function definition and no calls to them (this is property of all CallBacks).
In case of any syntax error command execution should return with similar error:
Błąd walidacji skryptu

Have a nice Scripting Time!


How to remotelly trigger run advertisement on SCCM 2012 Client

Hello Everybody,

there is many questions on the web about remote invoking SCCM actions on the client via scripting.
Within official SCCM 2012 SDK, there is absolutelly nothing about such client actions. Within the 2007 version it is demonstrated, but with local script and invoking the CPAppletMgr in conjuction with UIResourceMgr COM object class. But configuration of DCOM for accepting remote request for this objects is at least tricky and useless because it is dummy to beleve this classes will not change in the future.
Most natural way for SCCM to do this is create apropriative WMI calls.
And here Microsoft makes new troubles for all of us, scripting guys – in new SCCM 2012 SDK is dry description of classes witin CCM namespace. But also absolutelly nothing as notes for using this.
Finally I have found brilliant tool: SMSCLICTR, what encapsulates all of settings within simple to use .NET assemblies. This can also be used within Powershell, but sometimes usage such external modules is prohibited.
So I have made own piece of code in Powershell for doing this manually.

  1. First of all I had to enforce current Machine policy refresh. I is done by following function:

    function ForceMachinePolicyRefresh
    param($clientname, $username, $userpass, $PolicyID)
    $ms = new-object system.management.managementscope
    $ms.Path = "\\$clientname\root\CCM"
    $ms.options.username = $username
    $ms.options.password = $userpass
    $mc = new-object system.management.managementclass($ms, 'SMS_Client', $null)
    $mc.invokeMethod("TriggerSchedule", $PolicyID)
    return $mc

    There are several things to explain within this code:

    • It connects to namespace with explicity manner, without any casting, because of credentials passing. This code can be invoked only remotelly, because setting $ms.options.username is supported only with remote connection.
    • It is general function for enforcing any scheduled action. So it can be used not only for Machine policy refresh, but also applying changes within localconfig, as you can see later.
    • Last thing connected with this small piece of code is fact it can be used as a base for manipulating any of published method within SMS_Client WMI class. Now the MS refrence from SDK can be helpfull.
  2. So, when we have this defined we can go further. Now the function for invoking exact advertisement of specified Package. Function takes all necessary arguments:

    function InvokeOptionalAdvertisement
    Param($clientname, $username, $userpass, $advertID, $packID)
    $mc = ForceMachinePolicyRefresh -clientname $clientname -username $username -userpass $userpass -PolicyID "{00000000-0000-0000-0000-000000000021}"
    $ms = new-object system.management.managementscope
    $ms.path = "\\$clientname\root\ccm\policy\Machine\ActualConfig"
    $ms.options.username = $username
    $ms.options.userpass = $userpass
    $query =new-object System.Management.ObjectQuery
    $query.QueryString = "Select * From CCM_SoftwareDistribution where ADV_AdvertisementID = '$advertID' and PKG_PackageID = '$packID'"
    $searcher = new-object system.management.managementobjectsearcher($query)
    $searcher.Scope = $ms
    $advs = $searcher.Get
    $enum = $advs.GetEnumerator()
    $adv = $enum.Current
    $adv.SetPropertyValue("ADV_RepeatRunBehavior", "RerunAlways")
    $adv.SetPropertyValue("ADV_MandatoryAssignments", "True")
    $query1 = new-object System.Management.ObjectQuery
    $query1.QueryString = "Select ScheduledMessageID FROM CCM_Scheduler_ScheduledMessageID like '" + $adv.ADV_AdvertisementID + "-" + $adv.PKG_PackageID + "%'"
    $searcher1 = new-object System.management.managementobjectsearcher($query1)
    $searcher1.scope = $ms
    $scheds = $searcher1.Get()
    $scheds | Foreach-Object { $mc[1].invokeMethod("TriggerSchedule", $_.ScheduledMessageID) }
    return $adv

    So now a word of comment for this function:

    • On the beginning we invoke machine policy refresh with our previously defined function
    • Next we define new management scope with namespace of actual config, what is used by CCM.
    • After that we need the ObjectQuery instance for encapsulating correct WMI Query. This query select all CCM_SoftwareDistribution objects, what matches our conditions
    • by usage of searcher object we obtain all required object to $advs variable
    • trick with enumerator and him Current property gives us only one object, instead of containing it collection
    • now we do main Job. We modify two properties, what ensures that optional assigment is now mandatory and will run on next schedule of this Advertisement
    • last part of the script gets proper objects of schedulers for our Advertisement and Package.
    • finally we trigger the schedules and task sequence runs properly.

“The AD RMS installation could not determine the certificate hierarchy.” error during AD RMS Reinstall

There are rare situations, when you have to reinstall the RMS Cluster node. Most common case causing such need is unsuccessfull provisioning process. It usual fails because of really obvious things, such as already binded SSL certificate to Web Site in IIS. After unsuccessfull provisioning task, you have to uninstall whole AD RMS role and after the server restart you can try again with installation. Unfortunatelly sometimes there are the errors during uninstall too. This hidden errors causes subsequent issues during next attempt.
The error cited in post title has several different potential resons and solutions. Most of them is improper registry settings, which stayed after previous install. One thing, what you have to always remember, is that you have to check twice need of every registry change. Inproper registry edition can causes whole server operating system damage.
Namely described error can be caused by one of the following reasons:

  1. Wrong Service Connectin Point – it happens because of improper value in Active Directory container under following path CN=SCP, CN=RightManagementService, CN=Services, CN=Configuration, DC=domain, DC=lab, what point to nonexiting RMS Cluster service URL. More information about this cause you can obtain here. This reason is explicite mentioned in error message shown at the end of role installation wizard.
  2. Second possible issue is described in Application log entry with Log ID 204. This is because of lack of one value in the registry. The mentioned article provides procedure for recreation of missing registry values.
  3. If no of previous solutions helps, I found third one. You need to verify content of following registry hive HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS. If there is any value or key this can cause an error. You have to examine it and remove any value, which is pointing to non existing service URL. After this hive clean up, there should be only one value. This is the (default) one.

If your situation doesn’t follow any of described cases, please fell free to put me message in a comment.


Microsoft Enterprise CA doesn’t allow to publish templates V2 and V3

Under some circumstances after installation Windows Enterprise Operating System and configuration of AD Certification Services as Enterprise CA, the CA Services still doesn’t allow publication of certificate templates in versions higher than V1. This is because of misconfiguration of registry entries, which determines type of CA installation as Standard.
Okno Publikacji szablonu
The solution for this problem is proper setup of bit flag in the CA configuration. It can be done with following command:
certutil -setreg ca\setupstatus +512
After registry update, there is necessity of restart CA service.
More over, there is possibility of manual edition of the templates list, which is used by CA for certificates enrollment. It is possible by edition of attribute certificateTemplates in object pKIEntrollmentService. These objects are available under following path CN=Internal Issuing CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contonso,DC=lab


Installing Service Pack 1 for Windows 2008 R2 by MDT 2010 U1 mechanizm

Today post is about why sometimes using manual can harm your things.
It is normal, that if you doesn’t know how invoke application in other way than simple double click on exe file, you call the command line
aplikacja.exe /? or aplikacja.exe /help
In the response we obtain in any form some information about command line switches handled by this program. Especially, we can obtain in this way information about advanced method of calling standalone windows operating system updates.
The Windows 2008 R2 Service Pack 1 installator responses with following:
Dialog window with help for Windows 2008 R2 Service Pack 1
For import process to Microsoft Deployment Toolkit, you have to unpack in any way the exe file to the Windows Standalone Update (msu or cab) files form. On the screen there is no such option.
But after several unsucessful tries I figured out that this command line:
windows6.1-KB976932-X64.exe /extract
fires up exactly this extraction process without any error message. First simptom of right execution was dialog window with directory tree for choosing proper location for extracted files. There is also the cab file, what is necessary for update usage with MDT 2010 U1.

I am only curious, why Microsoft doesn’t add it to the help screen.


DHCP configuration in Windows 2008 R2 Core

Sorry, this entry is only available in Polski.


Certification Authority Service installation on Windows 2008 R2 Core

Today I’ll write about something completely new. Certification Authority Services, called AD CS (Certification Services) was added to the Windows Core distribution only in the R2 release. Windows Core themself was introduced as an installation option in the Windows 2008 release.
There is a lot of materials covering the Core installation, so I won’t describe it wider. For example, I suggest to read this Nataniel Zieliński’s article. For the moment, it is enough to know, that there is almost no graphical user interface. The system is managed from command promt. There is also very good Getting Started Guide what can help start up with Core installation, but most of new features introduced in R2 relase are still poorly documented.
The CA server installation requires using Add Role Creator on regular Windows 2008 R2, which is unavailable under Core version. So the first step is installation of service’s binaries. It can be done with following command:
start /w ocsetup.exe CertificateServices /norestart /quiet
Next really usefull step is to check corectness of installation. We can do that typing the following in the command prompt:
oclist find /i "CertificateServices"
After getting sure, that we have whole service’s package, we need to configure it. It can be done with VBScript program, which performs the automatic installation. It is available under following link. This script can help us avoid our headaches through simple and quick installation of our CA Service. But we still need to provide set of parameters which regulates its work. Full set of possible switches is provided on the script’s web page. Here, we need to pay attention that parameters:
are not supported under Core installation.
Moreover, before performing CA Service installation process in Core as well as Regular distribution we need to prepare the CApolicy.inf file, what must be placed under %SYSTEMROOT% directory. There is example code of such file:
Signature="$Windows NT$



NOTICE=Certificate issued under Test CA Policy


After the installation it is worthy to set up CDP (CRL Distribution Point) parameters with following commands:

certutil -setreg CA\DSConfigDN CN=Configuration,DC=DOMAIN,DC=LAB
certutil -setreg CA\CRLPeriodUnits 14
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 7
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Hours"
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:http://pki.test.domain.lab/repozitory/%%3%%8%%9.crl\n65:file://\\%%1\CertEnroll/%%3%%8%%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:http://pki.test.domain.lab/repozitory/%%1_%%3%%4.crt\n1:file://\\%%1\CertEnroll/%%1_%%3%%4.crt"
certutil -setreg CA\AuditFilter 127
certutil -setreg CA\ValidityPeriodUnits 2
certutil -setreg CA\ValidityPeriod "Years"
net stop certsvc & net start certsvc
certutil -crl

Creation of such, or simillar script will help us ommit of “clicking off” Certificate’s parameters under remotely connected Management Console. At the end I would add, that the first article what helped me with start working with CA Services on Windows Core was this Eyalestrin’s article.


lenistwo.. Sprawco wszystkiego!

No tak. To prawda. Gdyby nie lenistwo nie było by niczego. Tego sukcesu także. Mój UPS zepsuł się dawno. Tak dawno, że zdążyła mu gwarancja wygasnąć, pomimo, że usterka miała miejsce jeszcze w trakcie jej trwania. Po prostu nie chciało mi się zadzwonić do kuriera, żeby zawiózł urządzenie serwisu na ich koszt. I tak sobie bezużyteczny stał. Nie chciało mi się go do tego serwisu wysyłać, bo wrócił z niego dalej uszkodzony….

Mniejsza z tym. Kiedy dziś mnie lekko zezłościł swoją bezużytecznością, i zajrzałem do karty gwarancyjnej, to wyobraźcie sobie, z jaką ulgą odetchnąłem : “Nareszcie mogę go otworzyć ja”. 😉 Po czym zabrałem się do dzieła.

Po otwarciu jakże schludnego i marketingowo nieskazitelnego “opakowania na elektronikę” zdębiałem. Panowie z serwisu producenta faktycznie wymienili akumulator, tak jak w karcie gwarancyjnej stoi, ale nie raczyli już odczyścić płytki z rozlanego elektrolitu. Zabrałem się do sprzątania.

TAK! Sprzątać po serwisantach wewnątrz urządzenia – to jest to, co tygrysy lubią najbardziej 😀 Aceton, Kwas Solny i te sprawy… W między czasie się okazało, że elektrolit rozpuścił jakieś pięć centymetrów przewodu wewnątrz izolacji – trudno – sztukować też trzeba umieć, gdy się w serwisie pracuje. Potem w ramach emulacji złącza, które się kompletnie rozlazło, dwie zworki zlutowane z przewodami, i GOTOWE.

Tak oto mój UPS został naprawiony.

Ale to nie koniec zabawy. Jak powszechnie wiadomo, tego typu urządzenia są montowane w różnych wersjach: tańszych i droższych. Teraz wystarczy się zorientować, czego nam producent poskąpił na płycie głównej, i mamy wersję extended 😉 Dokładnie w ten sposób mój model dorobił się wskaźnika ładowania aku. Teraz jeszcze pozostaje wywiercić otworek w obudowie 😀

Tak że czasem strach przed serwisem bywa twórczy. A wybór metody zależy od Ciebie, Drogi Czytelniku.