Speed up your OSD time

sccm

When looking at decreasing the time it takes for your OSD. There are three things you will want to look at. These are, configuring dynamic variables to specify what your reboot delay should be on steps that require a reboot, the sms agent host service and power management settings. By default, your reboots will take 1 minute so this is theoretically 2-3 minutes between steps where you have specified a reboot. The SMS agent host service is set by default as a delayed startup so this eats into time for your OSD too and lastly power management is set to default, you’ll want this on high performance.

First create a step in your task sequence and choose Set Dynamic Variables, in this I have specified the 4 variables, there are probably more that you can put in here but these are the ones I use:

SMSTSAssignUsersMode - Auto

SMSTSAssignmentsDownloadInterval - 15

SMSTSRebootDelay - 0

SMSTSPostAction - cmd /c gpupdate /target computer /force /wait 0

The next thing you’ll want to do is create a Run Command Line step to configure your power management options. In the command line, what you’ll want is:

PowerCfg.exe /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

For the above to work, you will also need to create a package which contains powercfg.exe executable which you can take from any windows 10 machine.

 

 

Doing this you will shave off 50% off your time. It is also worth going through your task sequence and removing any unnecessary reboot steps.

Lastly,

Just after the Setup Windows and ConfigMgr step, I have set the SMS Host Agent to Auto using a command line step.

cmd /c sc config "CcmExec" start= auto

From doing this, I got my imaging time down from 1 hour 12 minutes to 26 minutes so it has helped significantly.

 

Can’t connect to SQL instance using Windows Authentication

Can’t connect to SQL instance using Windows Authentication

Windows

I had an odd issue at work where I could not connect to a SQL server using Windows authentication even though I had the authentication set to mixed mode. I was able to logon with the SQL authentication details but not with Windows authentication. I was presented with the following message – “The target principal name is incorrect. Cannot generate SSPI context.” When looking into this it turned out that the SPNs were registered to a user object that did not run the service on the host of where the SQL Server was running. I use service accounts for SQL server, this one named SCCM-SQLSRV and this did not have the SPNs registered to it.

To find out the user object/computer object that the SPNs are registered to you must first run the following command. Replacing $Computername with the hostname of your server and $FQDN with your fully qualified domain name.

setspn -Q MSSQLSvc/$Computername.$FQDN

This will bring back which computer object/user object the SPN belongs to like so:

Checking domain DC=contoso,DC=com

CN=AccountThatHostsTheSPNs,CN=Service Accounts,DC=contoso,DC=com

From this, we see that the SPN is registered to a hypothetical user object named “AccountThatHostsTheSPNs”.

What we must now do is unregister the SPN. For this instead of using -Q we use -D.

Now we must register the SPN, again using the setspn command or if you really wanted to you could go to the user object in AD and go into attributes editor and do it that way but for the purpose of this guide, I will stick to using setspn. So this time we use the A parameter and append the user object to the end of the command to which you would like it registered to. If you’re using local system on the SQL service then this would be the computer object. If this is a user object, you must also make sure that the user object has AD permissions on the computer object of the SQL server to read and write Service Principal Names.

setspn -A MSSQLSvc/$Computername.$FQDN $UserObjectYouWantToRegisterTheSPNTo

 
You test that this works by issuing a kerberos ticket for this SPN, I did this initally which pointed me in the right direction as to what was wrong. You can also test and find out which user object it should be registered to this way.

Previous to doing this fix, when I issued a kerberos ticket, I would get the following critical warning in the event log. Which pointed me to the solution to why this error was coming up and I could not authenticate.

The Kerberos client received a KRGB_AP_ERR_MODIFIED error from the server SCCM-SQLSRV. the target name used was MSSSQLSvc/sccm.contoso.com:1433. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target principal name (SPN) is registered on an account other than the account the target service is running. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (contoso.local) is different from the client domain (contoso.local), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Remember to restart the SQL service once you’ve updated the SPNs. It should then work. I hope this helps somebody as I was coming up blind trying to google this one.

Setting up a reverse proxy using nginx for your FREENAS jails

Setting up a reverse proxy using nginx for your FREENAS jails

FREENAS, GNU/Linux, nginx

I am a big user of FREENAS and the goal behind this was to have one domain and to redirect the requests for my jails using, “jails/sickrage”, “jails/sonarr”, etc…

In order to do this, what you need to do is get an nginx server up and running. For this, I simply created a Linux Jail template and installed nginx.

This post makes the assumptions that you are using FREENAS, you are proficient in using vi or nano and that your jails are properly configured to handle reverse proxies, if not, I can do a guide on this in the future for the things you’ll need to configure for them to work correctly and you know how to set up a custom jail.

On your nginx server, locate the nginx.conf file. You can do this by using the find command in Linux but for me this file is located in /usr/local/etc/nginx, this may vary on the distribution that you use.
Now edit this file with your editor of choice.

Locate the following line: server {
Specify a server_name in my case, I named it jails.

Underneath this line type include proxy_setup.conf; (you could do the below all in the nginx.conf file but this way it’s cleaner.)

Now save and exit this file.

Now we will create a file named proxy_setup.conf in the current directory.

The general rule with this file is as follows:

    location /couchpotato {
     proxy_pass http://192.168.0.101:5050;
     proxy_redirect off;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     }

     location /sickrage {
     proxy_pass https://192.168.0.102:8081;
     proxy_redirect off;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     }

     location /web {
     proxy_pass http://192.168.0.103:32400;
     proxy_redirect off;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     }

     location /ntopng {
     proxy_pass https://192.168.0.1:3000;
     proxy_redirect off;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     }

     location /sonarr {
     proxy_pass http://192.168.0.105:8989;
     proxy_redirect off;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     }

     location /sabnzbd {
     proxy_pass http://192.168.0.106:8080;
     proxy_redirect off;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     }

The parts that you will need to change is proxy_pass and location.

This is my current working configuration. Remember, you will need to configure the jails to handle reverse proxies otherwise they won’t work. Generally, you just need to go into the .ini file of the jails and change handle_reverse_proxy = 0 to handle_reverse_proxy = 1 and to change the URL base/web root of the jail to match that of the location specified in your proxy file that points to that jail.

Enjoy not having to remember the IPs and Port numbers for each of your jails 🙂

Nathan

Chromecast devices not discoverable on Linux

Chromecast devices not discoverable on Linux

GNU/Linux

The documentation from Google indicates that the Google Cast extension is not supported in Linux, but it actually does work. In order for it to work you must configure iptables to allow the uPnP/SSDP traffic used by the Google Cast browser extension to discover the Chromecast Devices.

The browser will send a multicast UDP packet from the local IP and an ephemeral (random) port to 239.255.255.250 port 1900. The ChromeCast device will respond with a unicast UDP packet from the ChromeCast device’s IP and another ephemeral port to the source IP/port of the multicast packet. Note that this is slightly different than most other UPnP devices, which will usually respond with a unicast UDP packet from port 1900 instead of an ephemeral port.

You will need to add a rule to accept UDP packets on all ephermeral ports. The ephermal port range for the inital multicast packet should be 32768 to 61000.

iptables -I INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT

Once you have made this change in iptables you must restart the browser. You should now find your Chromecast devices to be discoverable in Chrome.

How to properly end a KDE session from shell without root privileges

How to properly end a KDE session from shell without root privileges

GNU/Linux

To end a KDE session from the shell without root privileges what you can do is send a logout command via dbus to KDE. This then should terminate the session.

The command is as follows:
qdbus org.kde.ksmserver /KSMServer logout 0 0 0

dbus is a messaging system that lets applications communicate with each other, and the qdbus command is a utility for sending dbus messages to applications.

Applications register with dbus, and the ksmserver part of KDE is the session manager – it looks after who is logged in.

So we are sending a message to ksmserver to the /KSMServer interface and telling it to logout. The message we are sending is the exact same message that is sent to KSM when you click on the logout icon on your desktop.

The three zeros are parameters and can alter the type of logout we are doing:

First parameter:

0 = Do not wait for confirmation
1 = Wait for confirmation (with a 30 second timeout)
Second parameter:

-1 = Prompt for action, defaulting to shutdown (Only makes sense when waiting for confirmation.)
0 = Logout
1 = Restart
2 = Shutdown
The third parameter is the “when” parameter, but it isn’t clear what its impact is.

This is especially useful for when you are having an issue with your session and by doing this, prevents you from having to do a force shutdown as once you’ve terminated the session, you can start a new one from the terminal.