BusinessCentral switching login to AAD

We hade set Windows login in Business Central on premises instance and during database refresh was requested to add login via Microsoft Entra.

The process has nothing to do with the database. All configuration is local. It is well described in this official documentation. What I did.

1. IIS site, tab Authentication, Windows Authentication Enabled on HTTP 401 Challenge
2. IIS site file root
1. find file navsettings.json in C:\inetpub\wwwroot\BCDEVname\
   
2. switch ClientServicesCredentialType to value "AccessControlService"
3. restart IIS
   
3. Microsoft Entra App registration settings
1. create new registration https://entra.microsoft.com
   
2. set redirect URI https://xxx.xx/SignIn
3. api permissions for "User.Read"
4. expose an API
1. set application ID uri to the format of https://xxx.xx/ ideally
5. go back to overview and click button "Endpoints" to see URLs
   
4. MMC console for Business Central button edit
1. Tab general
   
1. Credential Type: AccessControlService
2. Uncheck "Disable Token-Signing Certificate Validation"
2. Tab Azure Active Directory
1. Application Client ID: <insert ID from App registration in Azure>
2. WS-Federation login endpoint: https://login.microsoftonline.com/<tenantID>/wsfed?wa=wsignin1.0%26wtrealm=<applicationApiIdUri>%26wreply=https://xxx.xx/SignIn
3.  Metadata endpoint: https://login.microsoftonline.com/<tenantID>/FederationMetadata/2007-06/FederationMetadata.xml
5.  save and restart BC instance
1. if errors then check event viewer on server: Windows logs / Application.

Next time you open https://xxx.xx/ you will be redirected to AAD Entra login page.

Jak používat GoPro jako webkameru

Při vylepšování svého pracovního místa jsem dospěl k závěru, že má webkamera z notebooku na mě kouká ze špatného úhlu. Nemyslím tím z podhledu, který se dá vyřešit elegantně za pomocí stojánku počítače, ale z boku. To je pro mě během delších hovorů ergonomicky nepohodlné. Rozhodl jsem se proto vyřešit to přidáním webkamery v ose mého hlavního monitoru.

Kvalitní kamera je stejně jako cokoliv se slušným obrazovým snímačem docela drahá věc, hodí se proto využít již vlastněné kusy. Moje GoPro používám specificky nárazově (většinu času leží ve skříni) a má vestavěný mód webkamery. 

Začnu mechanicky: Umístění na horní hranu monitoru jsem vyřešil za pomocí 3D tisku, kdy jsem si vytvořil stojánek. Úzký rámeček monitoru je pro umístění přídavné webkamery docela problém. Model naleznete tady, kamaráda s tiskárnou snad také.

Na připojení k počítači je třeba USB-C kabel, který má také datový přenos. Je potřeba jej připojit do dobře napájeného portu, kdy například USB hub monitoru nedokázal zajistit dostatečný příkon. Mám svůj počítač v dokovačce, u které jsem vybral modrý port USB 3.0.

Připojené GoPro se zahřívá a je po celou dobu vlažné. Nemám ponětí, kolik spotřebovává energie, ale nějaká to bude. Já ho používám s vyjmutou baterií, abych nesnižoval její životnost. Pro elegantnější vzhled mám nasazená pass-through dvířka.

Softwarová obsluha: Pro přítomnost webkamery v menu aplikace Teams a jiných je potřeba mít nainstalovanou a spuštěnou podpůrnou aplikaci. Přenos probíhá pomocí systému RNDIS přes síť, kdy je vyžadovaná výjimka ve firewallu. Tušíte správně instalace potřebuje administrátorská práva a třeba naše korporátní IT z toho nebylo u pracovního laptopu nadšené.

Jestli se potýkýte s chybovou hláškou že připojení selhalo a používáte Avast je to tím, že připojení k síti GoPro RNDIS Device s IP adresou 172.24.183.53 je považováno za nedůvěryhodné a musíte tuto síť přidat do výjimek.

Upozornění GoPro (stále) neumí používat vestavěný mikrofon jako zvukový vstup. I nadále tak potřebujete mikrofon na svých sluchátcích.

Přepínání čoček je možné přes zmíněnou obslužnou aplikaci a s možností náhledu hned porovnat změnu. Zde se přiznám, že ultraširoký mód mi přijde nevhodný pro kameru, kde chci snímat především sebe a tak mám nastavenu tu základní.

Před zpřístupněním obrazu do konferenční aplikace se zobrazuje načítací obrazovka. Je tam pár sekund prodleva, alespoň když je dokovací stanice s kamerou připojená protokolem USB do hostitelského počítače. S Thunderboltem by to bylo jistě rychlejší. 

Více problému mi dělá, když počítač přenesu do kanceláře, kdy je volbu kamery nutné manuálně přepnout v Teamsech, protože zařízení je díky běžící službě stále přítomné i když samotný hardware není. 

Jak výstup z kamery vůbec vypadá? Hezky, ale upřímně nepoznám moc rozdíl proti moderní vestavěné kameře s HD rozlišením. Jestli je ovšem vaše referenční video z nějaké 10 let+ staré webkamery, pak vylepšení kvality poznáte.

GoPro je použitelná náhrada za webkameru? Ano je, nicméně díky obslužnému softwaru není používání tak přímočaré jako u klasické USB webkamery.

Akční kamera však nepodporuje Windows Hello se kterým byste mohli odemykat uživatelský profil. Jestli potřebujete kameru, protože používáte notebook složený, tak toto není vhodnou volbou.

Update po dalších 3 měsících používání: S postupem času se řešení ukázalo jako nespolehlivé. Někdy se GoPro nepřipojí nebo zůstane viset na načítačí obrazovce v nejhorším případě havaruje celá aplikace Teams. Řešit tyto detaily je v momentě začínající schůzky krajně nepohodlné. Konečným zabijákem je pak chaos, který obsluhující aplikace vyvolává, když je GoPro mimo domácí replikátor. Řešení jsem nahradil konvenční USB webkamerou.

Soustavu jsem pak později doplnil ještě o mikrofon Sandberg Streamer USB s ramenem. Nikdo si na zvuk nestěžoval ani předtím, ale hezky to vypadá v setupu. Co je nemilé, že filtr na rozmazávání pozadí zneviditelňuje tento gadget, takže jej nikdo nemůže ocenit. 

Pro kvalitní obraz je potřeba nejen dobrá kamera, ale také slušné osvětlení, Já to vyřešil stolní lampou (LED bar) Logitech Litra Beam. Je skvělé, ale rozhodně není levné.

Poznámka pod čarou: Chtěl jsem zjistit jaká je má vestavěná kamera v notebooku Dell Precision 5770, nenacházím však žádné detaily než id USB\VID_0C45&PID_6732 a obrazové detaily "1 MP 1280 x 720 (HD) at 30 fps" z dokumentace výrobce.

Remote Desktop client login loop

I was experiencing issue with Remote Desktop app (with orange icon) for accessing AVD workspace. It was working in browser version, it was working on my iPad but I was unable to login from my private Windows PC.

I got into the workspace resources with my username and password in email format but RDP was not initiating and looping in login prompt:

the username and password used to connect to the remote resource didn't work

What I found was the source of problem: I had installed RDS client from Microsoft Store "Windows Store Remote Desktop app" but version from there is not working with AVD and Windows Server 2019. I had to get MSI installer and proceed with that. After that all worked smoothly.

Web client: https://client.wvd.microsoft.com/arm/webclient/

Windows client download: https://learn.microsoft.com/en-us/azure/virtual-desktop/users/connect-windows (get MSI package)  

Other platforms link: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients

Universal workspace URL: https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery

That's all, I hope it helped :)

Robot Framework show IP addresses

Recently I was struggling with an error message caused by the not opened firewall between Robot executing computer and the server hosting the website.

"WebDriverException: Message: unknown error: net::ERR_CONNECTION_TIMED_OUT"

So the straightforward solution is to fetch the public and/or private IP address of the machine hosting robot tests to do a proper firewall opening on port 80/443.

You can do it by following block which will print output to the console.

*** Settings ***
	Library Selenium2Library
	Library String
	*** Variables ***
	${BROWSER} edge
	*** Test Cases ***
	Network scanning
	[Documentation] Print network details of test execution machine
	${ip}= Evaluate [l for l in ([ip for ip in socket.gethostbyname_ex(socket.gethostname())[2] if not ip.startswith("127.")][:1], [[(s.connect(('8.8.8.8', 53)), s.getsockname()[0], s.close()) for s in [socket.socket(socket.AF_INET, socket.SOCK_DGRAM)]][0][1]]) if l][0][0] socket
	Log To Console Private IP is: ${ip}
	Open Browser http://api.hostip.info/get_json.php ${BROWSER}
	${ippublic}= Get Text //html/body/pre #get the IP address text
	Log To Console Public networking details are: ${ippublic}
	Close Browser

If it's hard to read, use this GitHub Gist with the same code. And that is all what was needed to do.

Here is how the output is looking like:

Postup přesunutí systémového disku na SSD

Toto jsou poznámky pro mě, až zase budu přidávat do počítače SSD disk namísto HDD (ano stále lze nalézt takové počítače). Klasiký problém je v tom, že původní HDD je kapacitně větší než nové SSD.

Nejjednodušším řešením je nová instalace Windows. Zvládne to i slepice, když nasypete zrní kolem tlačítka enter. Nicméně tento přístup je složitý v případě, že uživatelem počítače je starší osoba, která nemá ráda, když jsou věci jinak než byly.

Klonování disku řeší problém, systém zůstane na chlup stejný, ale všechno se zrychlí. Udělal jsem to po pár neúspěšných pokusech následovně:

• připravit si instalační Windows USB 
• vložit nové SSD do počítače
  
• odpojit původní disk
• udělat novou instalaci Windows do prvního restartu (formátování disku a kopírování souborů)
• zapamatovat si, jak velký byl oddíl na který jsou Windows nainstalovány
  
• odpojit nové SSD a připojit původní HDD
• zapnout "starý počítač" a vše zálohovat
  
• uklidit volné místo na disku, přenést velké soubory na externí disk
  
• změnšit systémový oddíl (partition s C:\Windows) přes diskmgmt.msc tak, aby byl o chlup menší než oddíl na novém disku
• připravit Clonezilla live USB klíčenku
  
• vypnout počítač a připojit oba dva disky
• zapnout clonezilla v režimu device-to-device
• pokračoval volbou partition-to-partition clone
• zkopírovat ze starého disku (source) oddíl s Windows
• do nového disku (target) oddíl s Windows
• vypnout, odpojit starý disk
• zapnout "nový počítač"
  
• buď počítač funguje automaticky, zkontrolovat běžnou funkčnost
  
• nebo provést automatickou opravu Windows
• ověřit, že nový počítač funguje jako ten předchozí
  
• vypnout a připojit starý disk
• po zapnutí namapovat písmena na starý disk, případně přeformátovat
• vrátit zálohovaná data na původní místo
• alternativně přemapovat složky dokumentů na starý disk

Pointou je, že nelze použít klonování starého disku na nový, protože se tam nevejde 1:1 (-icds). Proporční změna (-k1) mi udělala spoustu problémů a navíc klonovaný disk není správně bootovatelný. Secure boot není tak snadné obelhat. Při připojení celého klonovaného disku je potřeba změnit ID jednoty přes diskpart. 

Jednoduše zkopírováním pouze oddílu s Windows na místo předchozí instalace není třeba řešit žádné problémy se zavaděčem a skrytými bloky na disku. Stačí si pohlídat celkovou velikost partition.

Azure vm set tempdb location

It is possible to configure location for temporary databases internally used by SQL server to specified location during server deployment imperatively via Az cli. I realized that not all newly created VMs have that item available in JSON representation even GUI of Azure Portal is reporting some value.

Read query

az vm show --name <VMname> --resource-group <RG> --query resources[0].settings.ServerConfigurationsManagementSettings.SQLStorageUpdateSettingsV2.SQLTempDbSettings.DefaultFilePath -o tsv

Write command

az sql vm update --name <VMname> --resource-group <RG> --set resources[0].settings.ServerConfigurationsManagementSettings.SQLStorageUpdateSettingsV2.SQLTempDbSettings='{"DefaultFilePath":"D:\\SQLTemp"}' -o none

Some more configuration option

• SQLStorageSettings
• diskConfigurationType:"NEW"
• SQLTempDbSettings
• .defaultFilePath:"<path>"
• .storageWorkloadType:"OLTP"
• SQLLogSettings
• .defaultFilePath
• .luns
• SQLDataSettings
• .defaultFilePath:"F:\\data"
• .luns

I spotted that some VMs created from the image is not having the option available for reading TempDB location under ServerConfigurationsManagementSettings. It was possible to change basic SQLDataSettings and SQLLogSettings via RDP or SMSS tool but even that configuration didn't propagate to Azure. That happened because pre-prerequisites are not met.

 

Conditions to fulfill: There is an installed VM extension SqlIaasExtension and its state is deployed (visible via Portal). The second crucial condition isis that local user NT service\SQLIaasExtension has granted admin rights within the host. Last but not least the target location where is placed the defaultFilePath must be accessible for read/write/modify for a non-admin account or granted these rights for NT Service\MSSQLSERVER or granted local admin to that user as a whole.

 

It is easy to break SqlIaasExtension agent installation to get stuck in "provisioning" and then "failed" state. I have to discover the solution still to finish this tutorial.

Azure Classic Select-AzureSubscription Error

No default subscription has been designated. Use Select-AzureSubscription -Default <subscriptionName> to set the default subscription.

Select-AzureSubscription : The subscription id doesn't exist.
Select-AzureSubscription : The subscription name doesn't exist.
Select-AzureSubscription : Parameter set cannot be resolved using the specified named parameters.

Add-AzureAccount : No subscriptions are associated with the logged in account in Azure Service Management (RDFE). This means that the logged in user is not an administrator or co-administrator for any account

Add-AzureAccount : AADSTS50074: Strong Authentication is required.

I had the following problems with Setting the default subscription because of two reasons. For this you need to have set co-administrator rights

Solution: Add classic administrator role inside AAD for user you are using to log in. Azure Portal > subscriptions > subscription - Access control (IAM) > Classic administrators > Add > Add co-administrator and try again!

Non responding Azure VM

It might happen to your virtual machine in Azure Cloud too. It gets stuck without responding to enabled services like SSH, HTTP even pings; in Microsoft words "VM was not responding to any means of communication".

Symptoms: There is no answer from the public IP range as same as from a private network from a machine on the same VNET and subnet. A tricky part is a machine in the portal looks up and running, stopping, and restarting. 

I opened the M$ support case because it was another occasion of the same behavior and I wanted to know the answer. We went through a classic scenario: Restart, deallocation, and redeploy via the portal. The extra task was the restart VM's from the serial console but the serial console did not come up even after a reboot.

Short answer: one of the disks was incorrectly mounted. One of the logs was containing crucial information as "Reached target Emergency Mode" followed by

Failed to mount /var/lib/docker. See 'systemctl status var-lib-docker.mount' for details. Dependency failed for Local File Systems.

That failed mount is preventing VM to boot, it needs to be fixed as described below. We had to create a rescue VM for which we used the OS disk of the impacted VM to create a new VM and it worked.

Solution: add to mount point /etc/fstab an item -nofail. Save and exit. Detach drive and do OS swap for the machine. The reboot should be OK and the machine should be online.

How to rescue the VM

• Take the snapshot of OS disk - a full snapshot 
• In disks – Created new disk using source path as a snapshot.
• Verify the size of the disk and the type of disk used and used the same size and type to create a new disk.
• Attach the disk to an existing Redhat VM, swap the disk, and mount it.

These few hints might help you to get rid of the troubles.