26 March 2020

Howto: Folding@Home – Linux


The Folding@Home (F@H) team has released v7 (currently v7.5.1) of their F@H software. It has a newer simpler graphical interface aimed at making it easier for people to install and contribute to the project. Here is how to make it run on your Linux computer. Linux has been growing in popularity as a desktop OS, so it’s great to see projects like this include it as a viable platform for contributing to F@H.

You can find F@H’s official documentation for Linux here – https://foldingathome.org/support/faq/installation-guides/linux/

Install F@H

I’m going to use a 64-bit Ubuntu v19.10 desktop to show you how to install F@H. You can download the latest Ubuntu Desktop versions here.

1. Download the installer from here: https://foldingathome.org/alternative-downloads/ (link opens in new tab)

2. Click on the “fahclient_7.5.1_amd64.deb” installer.

2. Allow the file to open with the default software installer.

3. Click the ‘Install’ button.

4. Enter your password, if asked, to allow the F@H client to get installed.

5. Enter your F@H user and passkey, then click ‘Next’.
*Make sure to check the box to automatically start the FAHClient.

6. The install itself should be really quick.

7. Open a browser on your Linux machine and in the address bar go to: 127.0.0.1:7396

It will open the F@H webgui where you can watch your work progress or adjust settings.

8. Just like that you are contributing to F@H! The client will be running as a service in the background.

I know that I left my F@H username and passkey in my post. Go ahead and use my F@H username & passkey if you really want to… It just means my F@H user will get credit for any folding you do.

Category: Linux | LEAVE A COMMENT
26 March 2020

Howto: Folding@Home – Windows


The Folding@Home (F@H) team has released v7 (currently v7.5.1) of their F@H software. It has a newer simpler graphical interface aimed at making it easier for people to install and contribute to the project. Here is how to make it run on your Windows computer.

You can find F@H’s official documentation for Windows here – https://foldingathome.org/support/faq/installation-guides/windows/

Install F@H

1. Download the installer from here: https://foldingathome.org/start-folding/, or alternatively from here.

2. Double-click the file to start the installation.
If an UAC prompt is displayed, click ‘Yes’ to continue.

3. Click ‘Next’ on the Welcome screen to continue.

4. Read and accept the license agreement by clicking ‘I Agree’.

5. You have two options, do the ‘Express install’ or the ‘Custom install’. I am going to click the ‘Custom install’ to be able to have a bit more control over the installation.

6. Choose the install folder destination. I’m leaving it as the default.

7. Choose the folder for your data. Again, I’m leaving it as the default.

8. You have three choices as to when you want F@H to start; (1) At login, (2) As a service at boot, or (3) manually. You also have the option to enable a F@H screensaver.

9. Click ‘Finish’ to complete the installation.


Running F@H

1. If the F@H client did not launch or is already installed, click on it’s icon on your desktop or in your start menu.

2. The first time F@H runs, you will likely see a popup message from Windows Firewall, asking to grant F@H network access.

3. It will open the F@H in your broswer. Once open, click on the link to ‘Change Identity’.

4. Enter your F@H username, passkey, and team you want to be associated with.

5. After you have entered your user info, you can see your points earned and work units you have been assigned. That’s it! You are now contributing to F@H.

I know that I left my F@H username and passkey in my post. Go ahead and use my F@H username & passkey if you really want to… It just means my F@H user will get credit for any folding you do.

25 March 2020

WordPress – Set Timezone

I had originally thought that by setting the timezone on a Bitnami server that WordPress would then pull and use that time info. Oh, I was so wrong! It wasn’t a bad exercise, as at least I’ll be able to better read my logs in a more “timely” manner. LOL. But it turns out that setting the timezone info for WordPress is much simpler and doesn’t involve any need to console in or SSH to the server. Lets get started…

Log in with an account that has admin privileges to your WordPress dashboard. In the dashboard menu that is on the left side, navigate to “Settings” then click on “General”

The fifth item down from the top of this page is “Timezone”. Use the dropdown menu to select your desired timezone. Then click the “Save Changes” button at the very bottom of the page. I’m choosing “Honolulu” as my desired timezone.

That’s it! Your WordPress posts will now all reflect the local time you chose as your timezone. It couldn’t be any simpler than that!

25 March 2020

Bitnami – Set timezone

Having the correct timezone configured on your machine can save you a lot of “math headaches” when you try to comb through the machine’s event logs. It’s a pretty easy thing to configure in the overall scope of all things, yet it is one that is often over looked, even by veteran users. Never fear though… I will show you how you too can update your Bitnami instance to your preferred timezone.

Lets begin by logging in with ‘root’ priviledges to your Bitnami instance.
Once logged in, use the following command to see what timezone you are currently set to use.

date

As you can see in my example, I am currently set to the UTC timezone, also known as Universal Time.

To find our desired timezone and reconfigure this, we need to enter the following command.

sudo dpkg-reconfigure tzdata

Once you’ve entered the command above and hit ‘Enter’ it will launch a menu were we can find and select your desired timezone. I will changing my Bitnami instance to use the ‘Pacific\Honolulu’ timezone, also known as HST.

Once you click ‘OK’, the machine will show you that it has updated it’s clock to use your desired timezone.

You can further verify that your clock is set correctly by running the ‘date’ command again, just as we had at the beginning of this post.

date

Just like that, we have updated the timezone preference in Bitnami. It was simple to do just as i promised. No more “math headaches” for us when we read log timestamps!!!

NOTE: If you are just trying to update your timezone for WordPress that is running on Bitnami, then check out this post of mine: WordPress – Set Timezone

Category: AWS, Bitnami | LEAVE A COMMENT
25 March 2020

PhotonOS – Set timezone

PhotonOS is VMware’s minimalist Linux based OS that has been heavily optimized for vSphere environments. Many of VMware’s appliance and OVAs are based on this super light weight platform. The problem with appliances and OVAs, is that I have yet to find or launch one that is set to MY timezone by default. I guess that is the price I have to pay for living in Hawaii.

While having the timezone mis-configured probably won’t hurt the VM itself most of the time, it definitely makes reading timestamps and logs more difficult. I mean come on, we’ve all been there before, add or subtracting your timezone offset to figure out what time an event actually happened since we probably don’t live in the GMT or UTC timezones. Much to our luck, setting the timezone PhotonOS using SSH (or the console’s CLI) is pretty easy after you log in as ‘root’.

Enter the command below to get a list of all available timezones.

ls -lsa /usr/share/zoneinfo | more

If you live in a region that is divided into subregions, such as the ‘Pacific’, we can use the following command instead to list those zones.

ls -lsa /usr/share/zoneinfo/Pacific | more

Once you have found the name of your desired timezone you can use the following command to set it. I’m using “Pacific/Honolulu” as my desired timezone.

set Pacific/Honolulu timezone

Then make a symbolic link from localtime to “Pacific/Honolulu”, or your desired timezone…

ln -sf /usr/share/zoneinfo/Pacific/Honolulu /etc/localtime

The final step is to check and visually confirm that the timezone is correct. To do this, we simply run the following command.

date

Now we can finally make some sense out of our logs!!!

19 March 2020

CUCM 10.5 – Updating VMtools

Cisco Call Manager is an integral part of any company that runs it for all of their “voice” or telephony services. I’ll be honest… I’m always a little afraid to console in and do stuff on a CUCM server because I don’t feel like I know enough to quickly troubleshoot issues I might cause.

However that doesn’t mean that I can avoid CUCM all together. I do have to jump into a CUCM server occasionally. Like when it’s been virtualized and it’s time to update the version of VMware Tools (VMTools) that is running on it. Thankfully, that task is a lot easier than it might initially seem. I’ll demonstrate how to upgrade the VMTools on a server running CUCM v10.5.2.

In vCenter, select your CUCM server. Dropdown the ‘Actions’ menu and select ‘Guest OS’. Then click on “Install VMware Tools…”.

You’ll see a pop-up message, click ‘Mount’. This will make vCenter mount the VMTools iso in your virtual machine so that the guest OS can access the installer.

Now, login into your CUCM vm’s console as an admin, and enter the following commands.

admin: utils os secure permissive
admin: utils vmtools refresh

You will be prompted that the tools install will reboot the machine twice. Press ‘y’ and hit ‘Enter’ to continue….

If vmtools has not ever been installed on this vm, or if the install didn’t complete, you might see a message that stating that you need to manually restart the server. If so, enter the command it shows to finish the intsall by rebooting the server.

admin: utils system reboot

After the reboots are finished, log back in as admin to your CUCM server. Enter the following command.

admin: utils os secure enforce

That’s it! Your VMtools have been updated. The updated guest OS info should now be visible when you look at this CUCM vm in your vCenter.

13 March 2020

Hiding email address in O365 with hybird on-prem AD sync

So another gotcha when using O365 in hybird mode with on-prem sync is that you can’t hide a user’s email address [from address books and distribution lists] by using the Exhange Admin Portal. This is because the setting are made on-prem, and those defined values are simply pushing to your AAD tenant in Microsoft’s Azure cloud.

We used to be able to, from the Exchange Management Console on the on-prem server, just open the user and check a tick box to hide their address from everything. The work around isn’t much harder, it’s just buried deeper.

Open the user in your on-prem AD, and navigate the “Attribute Editor” tab.

Scroll down until you find the following attribute.

  • msExchHideFromAddressLists

Setting it to “TRUE” will make the email addess hidden.

Setting it to “FALSE” or “<not set>” will make the email address visible.

After you have made the desired change to the value of the attribute, you just need to wait for [or force] your on-prem AD to re-sync with your AAD.

12 March 2020

Alias emails in O365 with hybird on-prem AD sync

If you use O365 in hybird mode, with your tenant sync-ed to your on-prem AD or Exchange server, then you will definitely run into an issue if you try to add an alias email address to a user.

When you attempt to add an alias, or alternate, email in your Exchange Admin Center portal you will see this error message.

To get around this you’ll need to edit the user “local” from your on-prem AD. In AD, right-click and open the users’ properties. Select the tab “Attribute Editor”

You will want to look for and edit the following two attributes.

  • msExchShadowProxyAddresses
  • ProxyAddresses

Add the user’s alias/alternate email address into the above mentioned attributes in the form of: smtp:updatedname@domain.tld

That’s it. Now you just need to let your AD sync back up to the O365 cloud.

WARNING: If you add it in CAPS (SMTP:updatedname@domain.tld) then it will get interpreted as the default address and not as an alias/alternate email. Make sure that “smtp” is lowercase.

4 March 2020

MDT & Joining the Domain

An important part to any OS deployment is joining the computer to the domain. The whole point of Microsoft’s Deployment Toolkit (MDT) is to automate as much of your deployment process as possible. So it is no surprise that MDT, when properly configured, can automagically join your newly deployed machine to the domain. It’s actually pretty easy to setup.

Part 1

The first part of allowing MDT to join machines to the domain is to setup a unique service account specifically for the task of joining machines to the domain.

Microsoft has helped to make things easier for us and has created a PowerShell script that can be downloaded, placed on your Domain Controller, and run to set a service account up with all of the necessary account permissions to manage computer objects in a specified OU. The script and instructions can be found under ‘Step 1’ at this link: https://docs.microsoft.com/en-us/windows/deployment/deploy-windows-mdt/deploy-a-windows-10-image-using-mdt

Part 2

The second part is going to be adding the correct values into your CustomSettings.ini file. There are the four variables that we need to add to automate the domain join, and one recommended value to skip the corresponding Domain Membership page in the Task Sequence wizard;

  • JoinDomain = The domain we are wanting to join.
  • DomainAdmin = The username of the service account we created earlier.
  • DomainAdminDomain = the domain that the service account resides. It’s typically going to be the same as the ‘JoinDomain’ value, but depending on how your AD Forest is configured, it is possible that it could be a different domain.
  • DomainAdminPassword = The password to our service account.
  • SkipDomainMembership = Yes/No. A ‘Yes’ value will skip the wizard page that asks about domain membership. A ‘No’ value will show the domain membership page.

Here is an example of how it would look when entered into the CustomSettings.ini file.

JoinDomain=MyDomain.tld
DomainAdmin=MDT_DJ
DomainAdminDomain=MyDomain.tld
DomainAdminPassword=Abc123456&!
SkipDomainMembership=YES

One additional item you may want to add to your CustomSettings.ini file is a value to specify which OU object you want the newly joined machine to be added to.

  • MachineObjectOU = Active Directory OU object you want machines to added to. It’s where you would have specified when creating the service account and running MS’s PowerShell script.

Which would look like this in the CustomSettings.ini file.

MachineObjectOU=OU=Workstations,OU=Computers,DC=MyDomain,DC=tld

You’ll want to make sure the OU is properly set for your domain. However, if you prefer to not specify an OU, your machines will all end up in the default ‘Computers’ OU of your domain, no harm there, you will just need to then manually move them into their correct OU.

Here’s what all the combined values I covered in this post would look like when added to the CustomSettings.ini .

JoinDomain=MyDomain.tld
DomainAdmin=MDT_DJ
DomainAdminDomain=MyDomain.tld
DomainAdminPassword=Abc123456&!
SkipDomainMembership=YES
MachineObjectOU=OU=Workstations,OU=Computers,DC=MyDomain,DC=tld

With the service account setup and the values added to our CustomSettings.ini, your deployments should now have no problems getting joined to your domain. Congratulations! You’ve streamlined one more deployment task.

27 February 2020

Server Manager – Orphaned RDS

So I’ve seen this a couple times and I always forget how to handle it, so hopefully writing this down will help me remember for next time…

You are replacing some Remote Desktop Session Host (RDSH) with a newer server, and everything looks good-to-go. Back on your Remote Desktop Connection Broker (RDCB), you have Server Manager open, and you proceed to remove the old RDSH servers. Easy. You then go back to edit other properties in in your RDS deployment and – BAM – you get an error message that states:

The following servers in this deployment are not part of the server pool:
1. <Old.RDSH.ServerName>
The servers must be added to the server pool

Powershell to our rescue! On your RDCB, open up a PowerShell window as an Administrator. Run the command below.

PS C:\> Get-RDServer

This will return a list of all the Remote Desktop servers you have in RDCB as well as their installed roles. You should see your old, unwanted, RDSH server in that list. Next, we can enter the command below to remove our orphaned RDSH server.

PS C:\> Remove-RDServer Old.RDSH.ServerName RDS-RD-SERVER

This will remove the ‘RDS-RD-SERVER’ role. Now if you go back to your RDCB, and back to your deployment, everything should be back to normal. It is no longer expecting the “Old.RDSH.Server” to be a server that Server Manger manages. In fact, at this point you should be able to remove it as a managed server.

Note: RDS is a complicated beast. The above mentioned trick utilizing PowerShell has worked for me the couple times I’ve needed in my scenario. However, your mileage may vary depending on your environment.