Problems with Event viewer messages for AX

Quite ofter when I look in the eventviewer I can see issues that the Event ID text does tell me anything other than it is not possible to show the message. I got this today at a customers that is running AX so I descided to find the solution. The error message I got looked like this:

SNAGHTMLa609812

I searched around a bit and found a solutin online… turns out we need to create a registry key pointing to the correct file containing the event text. This could be a exe or a dll file.

Below is a link to the information and the entire solution. The short description is this:

  1. Open regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application
  2. Create a new key called Microsoft Dynamics AX
  3. Create a String Value called EventMessageFile and add the following text:
    C:\Program Files (x86)\Microsoft Dynamics AX\60\\Client\Bin\Ax32.exe

Best Regards

/Johan

Link:

https://stoneridgesoftware.com/ax-event-log-message-the-description-for-event-id-from-source-microsoft-dynamics-ax-cannot-be-found/

Creating a crash dump of a crashing service

Once in a while it happens that processes and services crashes and when they do you will need a dump. There are some ways to do this using for instance Sysinternals ProcDump, but at some of our customers they have policy do log inactive users of the servers and since ProcDump is running interactively that will not work.

Instead you can use Windows Error Reporting to do this and the good thing… it is builtin to Windows. Here is how you do it:

  1. Start Regedit
  2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps (if the LocalDumps key does not exist, just create it)
  3. Create a new key with name of the process you are trying to debug, in my case Ax32Serv.exe
  4. Under the key you just created you create the settings… in my case
    DumpCount = 1
    DumpType = 2
    Which means I want one full dump. The dump will end up in the default directory %LOCALAPPDATA%\CrashDumps (all of these settings are documented in the first link below)

And now we wait…

Links
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx
http://blogs.technet.com/b/kristinw/archive/2012/10/03/procdump-how-to-properly-gather-dump-dmp-files-for-crashes-and-hangs.aspx

Geeky Tricks: Replace Cmd with Powershell

Today when I was recording a Podcast, me and my co-hosts got into a discussion about if it was possible to replace cmd with Powershell in Windows (The reason for the discussion is that the keycombination Win + R, cmd, Enter is ingraved in our spine)… turns out it is 🙂

New-Item “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\cmd.exe” | Set-ItemProperty -Name “(default)” -Value “C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe”

If you want to revert just use:

remove-Item “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\cmd.exe”

Happy Powershelling

Johan

Manage Local Admin Passwords – Additional Comments

Todays work consists of implementing a system for managing local admin passwords for Servers and Workstations in an Active Directory Environment. I have used the method in the following (excellent) article series from the PlatformPFE team at Microsoft.

Part 1 – Overview
Part 2 – Random Password Generation
Part 3 – Secure Active Directory Attribute Update
Part 4 – Update Local Account’s Password
Part 5 – Logging The Update Process
Part 6 – Extending The Active Directory Schema
Part 7 – Managing Local Administrators Passwords

In short this series uses a new attribute in AD (set to confidential) to store the local admin password. The password is changed and written to the attribute using a powershell script which is run on every startup of a computer.

There are some aspects of the solution that where not completely obvious to me so I thought I would write the down so I won’t forget them:

The Confidential attribute is a flag that is set on the attribute which requires not only Read Permissions but also CONTROL_ACCESS to the attribute to be able to read it.

There are some limitations:

  • The confidential flag cannot be applied on most of the default attributes. It is however applied to some default attributes such as Bitlocker Recovery Keys
  • The CONTROL_ACCESS permission is default set for members of administrators and account operators in active directory which means that these users will always have access to to confidential attributes.
  • The CONTROL_ACCESS permission can only be set using LDP.exe (which I will explain later how to do). You will need to do this if you want to allow users not member of  administrators and account operators to access the local admin password

To set the CONTROL_ACCESS permission for the AD-MemberServers OU-Read-Attribute-LocalAdminPWD group (described in the series), do the following:

  1. Start LDP.exe elevated as a Domain Admin User
  2. Connect to your domain controller

    image

  3. Bind LDP to the domain using your user account

    image

  4. Turn on the tree view in LDP

    image image

  5. Browse to the OU where you set up permissions and open Security Descriptor

    image
     

  6. Double-click the ACL you set to open it and check the Control Access box. Click OK when you are done

     image
     
    Note: If you set up the  password solution for Workstations to you will need to repeat the procedure for the workstation OU

  7. Done

Addendum:

To verify if all computers have a local admin password set you can run:

$Filter = {(-not(LocalAdminPWD -like “*”))}
Get-ADComputer -Filter $Filter  -Properties LocalAdminPWD | ft Name,LocalAdminPWD

Links

http://blogs.technet.com/b/craigf/archive/2011/01/26/delegating-access-in-ad-to-bitlocker-recovery-information.aspx
http://blogs.technet.com/b/platformspfe/archive/2014/05/13/part-7-managing-local-administrator-passwords.aspx

Reset av Offline Files i Windows 7

Det händer ibland att man har kvar rester fån tidigare offline folders som synkas en gång i tiden. Man har sedan tagit bort servern och får därmed en massa felmeddelande i synccenter.

Microsoft har publicerat en artikel hur du “startar om” hela offline mekanismen, dvs tar bort cachade filer och kopplingar och börjar om från början.

 

http://support.microsoft.com/kb/230738

Print Spooler crashar…

Idag befinner vi oss i printerträsket…

På en maskin jag felsökte idag crashade printspoolern så for jag försökte göra något. Jag har varit inne och rensat upp på följande ställen:

c:\windows\system32\spool\printers
c:\windows\system32\spool\drivers
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\CONTROL\PRINT\

Trots detta vägrade spoolen starta och förbli så. Efter lite letande hittade jag följande lilla guldklimp. När spoolens crashar i Windows hamnar det en log fil i C:\ProgramData\Microsoft\Windows\WER\ReportQueue

Här kan man se exakt vad som strular. I mitt fall var det hptcpmon.dll så jag gick helt enkelt till C:\Windows\system32 och döpte om den till hptcpmon.dll.old och sen startar spoolern igen…

/JP

Boot from VHD

Jag har suttit och stirrat mig blind på BCDedit så jag tänkte att jag skall skriva ner det här en gång för alla.

bcdedit /copy {default} /d “Namn på Boot Entry”

BCDedit returnerar en {GUID} kopiera denna och stoppa in den i följande rader:

bcdedit /set {GUID} device vhd=[locate]\VHDs\windows7.vhd
bcdedit /set {GUID} osdevice vhd=[locate]\VHDs\windows7.vhd

[Locate] måste ersättas av t.ex [D:]. Observera att klamrrana skal vara kvar

/JP

Hyper-V som DC

Jag konstaterade igår att det kanske är bra med en DC i mitt labnät…. sagt och gjort, jag körde DC promo på min Hyper-V maskin (ja, jag vet att det inte är supportat Blinkar )

När den kom upp gick jag in i Hyper-V Manager och skulle skapa en ny maskin…  Jag valde vart den skulle ligga och klickade mig vidare… då hänger sig guiden och vägrar gå vidare.

Problemet är by design. Det är inte en supportad konfiguration att köra RemoteFX enablade virtuella maskiner på en domänkontrollant så jag fick vackert avinstallera RemoteFX.

Länk

Single Sign on with Remote Desktop Gateway

Jag var hos kund idag och skulle installera en intern remote desktop gateway. Kunden ville att användare på det interna nätet skulle kunna ansluta til en intern gateway för att på så vis publicera skyddade resurser.

Ett annat önskemål var att användarna skulle slippa logga in mot RD Gateway utan istället använda sin AD inloggning.

Lösningen är att använda en GPO inställning som heter User Configuration – Administrative Templates – Windows Components – Terminal Services – TS Gateway – Set TS Gateway server authentication method. Aktivera den och ställ “Set TS Gateway server authentication method” till “Use locally logged-on credentials”.

Om du nu går in och tittar på inställningarna i Remote Desktop Klienten för RD Gateway ser man att den är inställda till att använda Windows inloggningsuppgifter.

Links

http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx