Solved: “No row was found with id” when selecting row from Excel with Power Automate

I’ve been trying to automate the manipulation of incoming emails from an unnamed source that contains the users first and last name but not their email address and then send an email to that person.

Unfortunately, I am not able to compose an email address based on the first letter of their first name and full surname along with the domains as the domains could be different (and the naming convention too).

I was initially doing this with a case statement in Power Automate which is very ugly, inefficient and pretty laborious to set up and I also found out the hard way that there is a limit to the number of Case statements you can have – 25 in case (pun intended) you are wondering.

Don’t do this – it’s ugly, inefficient and hard to manage.

Spent some time today to switch to an excel lookup that will grab the first and last name from the email and then pull back the email address that should be used in Excel. However, it kept returning the error no row was found with id ‘First Last’ even though there was only one row with the value of ‘First Last’

The issue was that I had created a table in Excel for all of Column C through E and this includes lots of empty lines that the Get a row command will choke on. Fixed by defining the table in Excel to only contain the actual data that I needed such as $C$1:$E$80, Power Automate now only returns one value and the script continues on successfully.

Power Automate flow to read email, set some variables and send an email out

Critical error with WordPress – just reinstall again

I’ve been getting several occurrences of Critical error when attempting to access WordPress on this site and I’m not 100% sure exactly what is causing the issue – I suspect it’s the automatic upgrade breaking things but doing an in-place upgrade to WordPress after the issue occurs seems to fix the issue each time.

Initially I thought it was a recent upgrade to PHP on my host and several old plugins using invalid php code that was causing the site to fail, however renaming the plugins and the themes folder to .old did not fix the issue.

After downloading the latest version of WordPress and extracting the files over the top of the original install the site then became available. This then enabled me to login, rename the theme directory, rename plugins and everything continued to work.

This did mean it was a good opportunity to spring clean the site and remove some old plugins that were no longer required.

I’ve rearranged the sidebar, removed an odd paragraph that was displaying an empty box and removed duplicate category and tag links. I’m still looking for a new blog layout theme – a lot of the WordPress themes seem to be focused on either a 1-3 page product site or box sites that consist of as many short excerpt posts as possible on the main page.

I really don’t like the excerpt page option – as most of the time I’m wanting to read everything in the article that someone has written. It’s especially annoying in RSS readers when you then have to click through to the site to read the rest of the content and that typically results in an unsubscribe from me.

I’m hoping some of this will fix the site from being dropped by Bing Search engine – something I’ve been struggling with for a couple of months and so far the support team have been completely useless in answering why the site has been removed from the index.

Reinstalling Connectwise Automate (Labtech) on Linux machine after cloning a disk in Azure

Connectwise Automate / Labtech agent icon

This is a pretty basic post and doesn’t go into the requirements to do a Linux version of sysprep, but I needed to temporarily clone a RedHat server in Azure that had the Connectwise Automate agent on it this morning. After a reboot, the server was showing up in Automate as the same id as the previous server which is not what we needed.

The documentation for the Linux agent is pretty lacking and restarting agents did not seem to fix the issue.

By changing into the location of the Automate agent, you can run the uninstaller.sh app and then reinstall with a new installer.sh that is typically going to be already downloaded to your home/ltechagent directory. Poking around it was easiest to remove and readd as a new agent.

Documenting as I’m sure I or other people will need this again.

cd /usr/local/ltechagent
sudo ./uninstaller.sh
cd ..
ls  -al
#No lttechagent directory should exist anymore

#change to location where labtech installer was downloaded, typically in the home directory and already unzipped.
cd ~/ltechagent
chmod +x install.sh
sudo ./install.sh
ps -ef | grep ltech
#Should see two results of the agent running
#View results of install
cat /tmp/ltech_install_log.txt
#refresh Automate console to see machine showing up correctly

Fixed: Installing SQL Server Reporting Services (SSRS) prompts for key

Had an odd experience attempting to install SSRS on a 2019 SQL instance the other day where the software kept asking for the install key to install. Unfortunately I did not take a screenshot but after starting the install progress it asks for a key and refuses to take the key provided.

Other search results state to just enter the key that is obtained by either trying to reinstall SQL and grabbing the key that is displayed during the setup process or by grabbing the key from the extracted 2019\x64\defaultsetup.ini file in the SQL source folder (not the SSRS Install folder).

This didn’t help as the key was reported as being incorrect.

Using dbatools I figured I would try installing from the commandline to see if I would get any better troubleshooting logs. Attempting to install SSRS with the fantastic dbatools module with a -whatif parameter gave me a warning that the server was pending a reboot.

install-dbainstance -Feature reportingservices -path e:\sql2019\source\ -version 2019 -instancename localhost -whatif

Rebooted the server and the key was then taken on the subsequent installation attempt.

Not sure why the install just keeps asking for the key rather than displaying “You need to reboot”

Using Microsoft Graph Update-MgGroup with Certificate Based Authentication as a working alternative for Set-UnifiedGroup

Yesterday I had a fun time converting a PowerShell script that used the set-unifiedgroup powershell command that was originally running with basic authentication, to a script that would run using certificate based authentication so it can run against a tenant that uses Modern Authentication for office365.

There were quite a few hurdles to overcome so hopefully this helps other people.

Step 1 – Fix Office365 logins

Blank browser page that loads when attempting to log into Office365

The computer was initially generating a blank white page on the screen when attempting to log into the Office365 or Azure portal. This was resolved by resetting the browser settings in Control Panel / Internet Options. Clearing cookies and temporary internet files did not help for this step.

Step2 – Connect to Office365.

The ExchangeOnline module was already installed on the computer, but needed to be updated with

 update-Module -Name ExchangeOnlineManagement

The rest of this phase reduced the previous 5+ lines of code to log into Office365 to a one liner. There are quite a few steps involved in this, but App-only authentication in Exchange Online PowerShell and Security & Compliance PowerShell | Microsoft Learn is a good document to follow. Make sure that the SSL certificate is documented somewhere so that you get a reminder *before* the certificate expires. Once the certificate is uploaded to Azure and permissions are set it is possible to connect with

connect-exchangeonline -CertificateThumbprint "1a2b3c4d5e6f....." -appid "123abc-456def...." -organization "companyname.onmicrosoft.com"

Initially I thought that would be it, but after running the script I discovered the next big snag –

Step3 – Converting set-unifiedgroup to MS Graph module equivalent

The script gathered a list of Microsoft 365 distribution groups (or UnifiedGroups) in Office365 that had their access level not set to private and changed them to be private. The previous code was this

Get-UnifiedGroup -ResultSize Unlimited | Where-Object { $_.primarySmtpAddress -match 'companyname.onmicrosoft.com' -and $_.accesstype -ne 'Private' -and $_.HiddenFromAddressListsEnabled -ne 'true' } | Set-UnifiedGroup -AccessType Private -HiddenFromAddressListsEnabled $true -verbose

However, set-unifiedgroup is one of a few commands that cannot be used with Certificate Based Authentication and the msgraph module has to be used instead. The Microsoft documentation points this out but does not provide helpful information on how to actually get this accomplished. The linked information refers to api calls rather than using actual Microsoft Graph PowerShell commands and there were several gotchas in this process (hence this blog post).

First the Microsoft graph module needs to be installed on the computer with

Install-Module Microsoft.Graph

Step3a – Importing Microsoft.Graph.Groups

When importing the Microsoft.Graph module on the machine into PowerShell , not only did it take over 10 minutes to import, an error message is generated stating

Import-Module : Function Get-MgUserContactFolderChildFolderContactMultiValueExtendedProperty cannot be created because<br>function capacity 4096 has been exceeded for this scope.
Screenshot error stating Import-Module : Function Get-MgUserContactFolderChildFolderContactMultiValueExtendedProperty cannot be created because
function capacity 4096 has been exceeded for this scope.

This is due to the sheer number of commands available in the module and PowerShell 5.1 has a limit to the number of commands that can be used. Using PowerShell 7 is one way of fixing that issue but I was trying to reduce the amount of changes being made to this pc. By importing a subsection of the module with import-module microsoft.graph.groups the number of commands that are available is greatly reduced and the import is also a lot quicker. 10 seconds to run instead of over 10 minutes from above.

Step3b – Filter left

The original search returned all groups in Office365 and then filtered them locally. In this large organization, there are a significant number of groups returned and the lookup took several minutes to run. By passing a filter parameter I was able to reduce the number of groups significantly.

Unfortunately the filter parameter does not support accesstype or the primarysmtpaddress so these have to be filtered out by piping the groups to a select-object statement.

Get-UnifiedGroup -ResultSize Unlimited | Where-Object { $_.primarySmtpAddress -match 'companyname.onmicrosoft.com' -and $_.accesstype -ne 'Private' -and $_.HiddenFromAddressListsEnabled -ne 'true' }

becomes

$groups=get-unifiedgroup -filter {(hiddenfromaddresslistsenabled -ne $true)} | where-object {$_.primarysmtpaddress -match 'companyname.onmicrosoft.com' -and $_.accesstype -ne 'Private'} 

After making this change, the groups were returned in less than a minute.

Step3c – Changing from set-unifiedgroup to Update-MgGroup

The new command to modify the group is update-mggroup but the standard command does not have the ability to change the access type as per the documentation at Update-MgGroup (Microsoft.Graph.Groups) | Microsoft Learn

Screenshot for the update-MgGroup command that is missing the AccessType parameter

However, after switching the document to the Beta version of the api in the dropdown menu on the left, the accesstype parameter becomes available. The above screenshot shows AccessType is missing vs the screenshot below that includes this option.

Screenshot of the update-MgGroup beta command that includes the AccessType parameter

We therefore end up with the following commands to set the profile to Beta, load the Microsft.Graph.Groups subset of the module and then connect to Microsoft. Graph

Select-MgProfile -Name "beta"
import-module microsoft.graph.groups
connect-mggraph -clientid "1a2b3c4d5e-1234-1a2c3-a1aa-aa12b3456c7d" -tenantid companyname.onmicrosoft.com -certificatethumbprint "0a4f....fe"

I had issues with the next bit of code and ended up using my Exchange online connections to retrieve the groups that matched the criteria of not being hidden from the address list and where the access type was not private, and then using the ExternalDirectoryObjectID from those groups in the update-mggroup command from the graph module.

In theory I should have been able to search using the get-mggroup command but I was having issues getting the filters and search to work correctly. I could not get any results to come back for searches that included the companyname.onmicrosoft.com email address. As soon as I added that to the criteria the results came back empty. Due to time constraints I used the (admittedly) messy option of using Exchange to grab the groups and graph to update them.

$groups=get-unifiedgroup -filter {(hiddenfromaddresslistsenabled -ne $true)} | where-object {$_.primarysmtpaddress -match ‘companyname.onmicrosoft.com’ -and $_.accesstype -ne ‘Private’}

foreach ($group in $groups) {
update-mggroup -groupid $group.ExternalDirectoryObjectId -accesstype "Private" -HideFromAddressLists
}

Finally, the script was completed by disconnecting the Graph and the Exchange connections

get-pssession | Remove-PSSession
Disconnect-MgGraph
Stop-Transcript

Using the transcript option at the beginning of the script really helped in debugging this code as it’s meant to run from a scheduled task and viewing the transcript enabled me to see what the issue was and then decide to test further in an interactive session.

SQL, dbatools and Webroot

I have been busy working on a SQL server migration, and have come across a couple of issues.

Firstly, attempting to install or upgrade an SQL instance with Webroot on the machine generates an unauthorized action on the machine. Reviewing the error logs provides the following error

Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException
Message: 
Attempted to perform an unauthorized operation.
HResult : 0x84bb0001
FacilityCode : 1211 (4bb)
ErrorCode : 1 (0001)
Data: 
WatsonData = Uninstall@{145996FC-8E6B-47AB-BEA5-A84F12B72AF5}

Navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall┬áregistry shows the value {14599…..} is Webroot. Set server into unmanaged mode and then removing Webroot then enabled me to install SQL service packs.

I’ve also run into the same issue on new installs which leads me to the second issue.

I’m using dbatools to install with notes taken from the newly printed dbatools in a month of lunches. A book I purchased pre-pandemic and promptly forgot about but I finally got my hands on the book.

dbatools is a fantastic resource for SQL admins who want to automate everything and a common task is installing SQL.

Unfortunately there’s a typo in Listing 13.6 and 13.7 The parameter SQLUSERDBDATADIR that is coded into the sql config.ini file should actually be SQLUSERDBDIR

It took me a while to figure that one out. I then went to check out the books online only to find someone had found and reported the same error – yesterday!

The moral of the story is to check the books online first.

Also, whilst looking at my Manning books – I have a Powershell problem (or maybe with all these books I don’t!

Listing of Powershell books from Manning Publications

Fixed: The trust relationship between this workstation and the primary domain failed

Login dialog box showing The trust relatiionship between this workstation and the primary domain failed.

Yes, this old chestnut! Had this issue today on a server, but for some reason the standard netdom resetpwd command would not work.

Running the command netdom resetpwd /s:servername /ud:domain\user /pd:* would give me the error message “The machine account password for the local machine could not be reset”

Powershell to the rescue and the equivalent commands running on the affected machine fixed the issue

$c=get-credential

test-computersecurechannel -repair -credential $c

shutdown /f /r /t 3

Unfortunately I’ve had to this multiple times in the past and it’s about time I blogged the solution for my own reference in the future

Fixed: 161008 The source virtual machine doesn’t have a network interface or all the network interfaces were deleted when using Azure Migrate

I’ve been working on an Azure Migrate project at work this week and had an interesting issue after attempting to start a replication of the source servers. The configurations were brought in from the Azure Migrate assessment tool but I received an odd error that there was no connected network interface on the source server.

This is a very strange error as all the source servers do have network interfaces otherwise there would not be much point in migrating them up to Azure! The error id 161008 and messages of “No connected network interface is configured for the virtual machine” and “The source virtual machine doesn’t have a network interface or all the network interfaces were deleted” did not make much sense, however the recommendation of “If there is no network interface on the source machine, add one and then go to Computer and Network settings of the virtual machine to configure the network interface” was a slight clue.

error id 161008 and messages of No connected network interface is configured for the virtual machine" and The source virtual machine doesn't have a network interface or all the network interfaces were deleted

Part of the solution steps imply that you create a nic on the server, but as the server has not actually been created in Azure yet, this step is not possible and the source server obviously has nic’s already setup so no change can be made on that server.

After getting a second pair of eyes on the issue (Thanks A!) , we had an Aha moment in the Compute and Network section of the server setup. The Assessment had set the nic’s on the machine to Do not Create and Secondary Network. As there was no primary nic configured on this page, the error message above is generated. Setting the Secondary nic to Primary rather than Secondary enabled the replication to start successfully.

Screenshot of configuring Compute and Network for an Azure migrate server

2 lessons from this – Always ensure you have a primary nic configured when using Azure Migrate. Get a second pair of eyes for that fresh look at the problem as sometimes you just can’t see the wood for the trees.

Fixed: The Active Directory schema isn’t up-to-date, and this user account isn’t a member of the ‘Schema Admins’ and/or ‘Enterprise Admins’ groups.

Setting Primary Group to Schema Admins

Attempting to run an Exchange CU update on a server this morning and the server kept giving “The Active Directory schema isn’t up-to-date, and this user account isn’t a member of the ‘Schema Admins’ and/or ‘Enterprise Admins’ groups” error message when attempting to run setup.exe /Prepareschema /IacceptExchangeServerLicenseTerms as a pre-requisite installation step. My user account was a member of both of the groups but the error still occurred.

Changing the accounts primary group in Active Directory by selecting the Member Of tab and then selecting the Schema Admins group and selecting Set Primary Group, logging off and back on again led to the setup process completing successfully.

Don’t forget to set it back after the installation has completed.

Fixed: Powershell prompts to run scripts when importing sessions – change %temp%

Powershell Security warning

My new work computer has had issues attempting to run Office365 commands for a while. After successfully connecting to Office365, using connect-exchangeonline (as an example), I would get a security warning – “Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your computer. If you trust this script, use the Unblock-File cmdlet to allow the script to run without this warning message. Do you want to run c:\temp\temp\tmp_rnncyvj4.v10\tmp_rnncyvj4.v10.format.ps1xml?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is “D”):

And this would repeat with the appropriate .psm1 file too.

The usual solution is to use unblock-file or set-executionpolicy -remotesigned.

However, in this case the files are dynamically downloaded and will have a different filename everytime and setting the execution policy did not make any difference.

I ended up changing my temp folder from c:\temp\temp to c:\andy\temp and now I no longer get prompted.

Very odd behaviour that is not too annoying until you run scripts across all the office365 tenants!