After onboarding into Prisma Access, Cortex XDR live terminal connections were no longer working. There is an existing support document relating to these sort of issues: Enable Access to Cortex XDR There is a section for decryption issues (step 2); what is not clear on this page is that to allow live terminal to work you also need to exclude the following URL: lrc-eu.paloaltonetworks.com It is referred to in Step 3 but only from a point of view of access.

The Windows Graphics Tools are used for Direct3D application development. To install you need to open an elevated command prompt, then use the following to check if it is currently installed: dism /online /Get-Capabilities This will output the currently available options/packages and see if they are currently installed (state): To install the windows graphics tools use the following to download and install: dism /online /add-capability /capabilityname:Tools.Graphics.DirectX~~~~0.0.1.0 Which if successful should look like:

Due to a firewall issue, I needed to see if an update to PANOS was related to a change in behaviour. I wasn’t sure exactly when the firewall had been upgraded. Searching through the system logs did not seem to show PANOS version changes. Finally I found a mention in a support forum of debug swm history. In short: debug swm history | match 'install panos' Will give you the history of upgrades.

Sometimes you want to see exactly what a computer or application is trying to communicate with. Obviously you can take full a network packet capture and filter the results and correlate the behavior with the DNS traffic, but sometimes it is easier to watch these results live as they happen. One quick way to do this is use Wireshark, however not the full client but the command line version tshark. Tshark allows you to filter on specific facets of DNS giving you a cleaner output especially when you are only interested in domains that an application is talking to.

In a fully wired VMware lab using a virtual Palo Alto (PANOS 8.1.14-h2) VM-50 I could see really rather high latency: That did not make sense for a wired LAN. After some internet based digging I found this: Is higher latency normal on a VM compared to hardware? This referred to some rare issues with virtual Esxi Palo Alto’s and intel’s DPDK. Following the referenced link takes you to a Palo Alto support page showing you how to disable the DPDK which as it states in enabled as default.

I’m not sure if this is due to system in question being in the insider fast ring (Build 19041 version 10.0.19041), however when trying to create a storage space via the GUI I got the following error: Can’t prepare drives Close all applications that are accessing the drive and then try again. ‪The parameter is incorrect. (0x00000057)‬ You have to make sure the disks are clear of partitions otherwise they will not even appear in the create storage pool wizard.

In a previous post (3 years 4 months 2 days ago) I wrote about searching DHCP leases directly on a DHCP server which was rather limiting especially if you are in larger network. These days I use the following script from a management desktop running RSAT which automatically lists authorised DHCP servers in the forest and searches though all scopes: $AllDhcpServers = Get-DhcpServerInDC $result = @( @($AllDhcpServers).foreach({ @(Get-DhcpServerv4Scope -ComputerName $.DnsName | Get-DhcpServerv4Lease -ComputerName $.

On installing Raspotify on a new build of Ubuntu 19.10 for Raspberry Pi I saw the following error: Raspotify installer only runs on a Raspberry Pi Not too much information there. Going through the manual install procedure you end up something more meaningful: N: Skipping acquire of configured file ‘main/binary-arm64/Packages’ as repository ‘https://dtcooper.github.io/raspotify raspotify InRelease’ doesn’t support architecture ‘arm64’ So unpacking that a bit it seems that in switching to using Ubuntu Server from Raspbian on my Linux Spotify connect Raspberry Pi’s the architecture is ARM64 (ARMv8) rather than using armhf.

This is my process for upgrading HA Palo Alto firewalls. Some steps will depend on your HA configuration; if you are not using preemption then you can’t disable it etc. So where possible refer to the official documentation. To start off you should take named snapshots of the config and export them off the firewall just to be safe. Below are the steps: Primary Disable preemption, commit Fail over the firewall, CLI: request high-availability state suspend Note this will fail over the firewall Check connectivity now the secondary is active Install update and reboot After device has rebooted log in and check the tasks for a successful autocommit, CLI: show jobs all Enable HA, CLI: request high-availability state functional Secondary

Since Ubuntu 17.10 Artful, ifupdown has been replaced with Netplan. After each session trying to remember how to configure Netplan I seem to forget the locations and syntax. So this is for my aging memory. The configuration files for Netplan live in: /etc/netplan/ The default install of Ubuntu 18.04 leaves the following file: /etc/netplan/50-cloud-init.yaml As you can see the config file is in yaml. Unless specified manually the default install will give a simple file using DHCP.