Removing a Border on a Hyperlinked Image in SharePoint…

2017-07-27T00:01:08+00:00 February 23rd, 2012|Uncategorized|

THE PROBLEM:

I recently wanted to add a picture to Coretek’s SharePoint site, and I needed to easily attach a hyperlink (essentially, create a ‘button’).  I had no problem uploading the picture; but when I would try to insert the hyperlink itself, I would get an unwanted border around my picture.

 

Unwanted Border Around Image Unwanted Border Around Image

 

As you might guess, this takes away from a nice, clean, look of the page.  If you have multiple hyperlinked pictures next to each other of different sizes, then you really have a less than ideal look.

THE FIX:

After looking around and trying to select different image options (none of which get rid of the border), a simple and quick fix came to mind: the HTML code.  All you have to do is go in and insert the following into your HTML code:

border=”0” (that’s a zero, by the way)

 

The Secret's In The Code The Secret’s In The Code!

 

There you have it!  A quick fix to taking out the border on your inserted hyperlinked image.

 

 

Powershell – Handling Reserved Characters in a Password

2017-07-27T00:01:08+00:00 February 15th, 2012|Uncategorized|

Recently I was using PowerShell to update records in a SQL database.  Unfortunately for me, the SQL credentials contained a dollar sign ($); which is a reserved character in PowerShell. 

Originally, building and sending my connection string (including the password within the string as usual) resulted in a failure to log in.  Even after some inclination that the dollar sign might be problematic, and encapsulating it in single quotation marks within the connection string, the login still failed.

After confirming that the connection string was indeed valid (through other means), the trick that ultimately worked in PowerShell was to set the password to a variable as a literal string (meaning, wrapped in single quotes) and then pass the variable along with rest of the connection string.

 

$psw = 'dbp$$wd'
$sConnString = "Driver={SQL Server};Server=10.0.0.1;Database=DBName;Uid=db_user;Pwd=$psw;"

 

This approach will apply to other special characters as well. 

Good luck!

 

 

Finding Rogue KMS Servers in the Enterprise…

2017-07-27T00:01:08+00:00 February 8th, 2012|Uncategorized|

In larger Enterprises with Microsoft-based infrastructure, it’s highly likely that the licensing for the Windows 7 workstations will be based on the Microsoft KMS model.  If you don’t already know, this means you run servers in-house that register themselves into DNS as license providers, and Windows clients will learn of them (and become affiliated with them) to get a license, rather than contacting Microsoft themselves across the Internet.

Unfortunately, one problem that can occur is that someone who has access to the Microsoft license codes (like an I.T. worker, developer, etc.) might accidentally install a KMS license on a server that is not intended to be a KMS server.  And when a KMS license is installed, the server doesn’t know any better; and dutifully registers its KMS capability with the internal Active Directory based DNS as a VLMCS SRV record. 

Recently, I ran into a situation where I needed to hunt down and eliminate some accidentally rogue KMS servers that had cropped up across a large infrastructure, and be able to re-check at regular intervals.  While I originally wrote the script as a bash shell script for Linux, I re-wrote it into PowerShell recently for someone who asked, and I thought I’d post the new version here.

Mind you, this is a stripped-down version of the script, but it includes all that is needed to run the check manually for a hierarchical DNS infrastructure (although you may wish to strip out components if you just want to check the parent domain). 

Copy the contents below, paste them into a PowerShell script file (*.ps1), change the variables at the top… and have fun!

 

# Change the following 3 variables as needed.
# This script will loop through the subdomains, checking for KMS servers in each
# subdomain, and then at the parent domain.
$subs = @("subdomain1", "subdomain2", "etcetera")
$parentdomain = mydomain.local
$outfile = "checkKMS-Results.txt"
write "KMS check report..." | Out-File $outfile
write " " | Out-File $outfile -append
write "The only valid KMS servers are at the $parentdomain, as follows:" | Out-File $outfile -append
write "KMS1, KMS2, KMS3" | Out-File $outfile -append
write " " | Out-File $outfile -append
write "There should not be a KMS server at any of these locations:" | Out-File $outfile -append
foreach ($item in $subs)
{
  write "Checking subdomain: $item"
  $result = nslookup -type=srv _vlmcs._tcp.$item.$parentdomain. |findstr /C:"_vlmcs" /C:"svr hostname"
  if ("X$result" -eq "X")
  {
    write "No registered KMS server in $item" | Out-File $outfile -append
  }
  else
  {
    write "***KMS FOUND at this location: ***" | Out-File $outfile -append
    write $result | Out-File $outfile -append
  }
}
write " "  | Out-File $outfile -append
write "On the contrary, the following should be valid KMS servers:" | Out-File $outfile -append
$result = nslookup -type=srv _vlmcs._tcp.$parentdomain. |findstr /C:"_vlmcs" /C:"svr hostname"
$result | Out-File $outfile -append
write "...Done!" | Out-File $outfile -append

Enjoy!

🙂

 

Basic MSI – Public_Property as Component Install Location

2017-07-27T00:01:08+00:00 February 1st, 2012|Uncategorized|

Sometimes enterprise level packaging can be quite complex, having requirements for variables, sources, destinations, etc., that are all over the map — and all over the network. 

For instance, what if you are working with application bundle files in an MSI that are not intended to be local to the device?  In that case, how does one use a “public property” that contains a path to a network drive as the destination for files to be installed in a basic MSI?

Well, that leads us to this item from Kathy at the Flexera Community Forum:

“If you’re installing the file through a component, you can use a type 35 custom action sequenced after CostFinalize to set the destination folder for the component to the value in the property.”

This translates to using a “Set Directory” custom action.

Steps:

  1. Create a new component.
  2. Under the new component, create a folder under a location that will always exist (such as under the INSTALLDIR/TARGETDIR location).
  3. Add any files needing to be installed to said folder.
  4. Create a public property with the full destination path as its value (where you want the files to end up eventually).
  5. Create a “Set Directory” custom action.
  6. Source of the CA is the directory created in Step 2.
  7. Target of the CA is the public property created in Step 4 (inputted as
    [PUBLIC_PROPERTY]).
  8. Leave the rest of the CA choices as the default options aside from the “Install Execute Sequence”.   Change the setting to “After CostFinalize”. 
  9. Complete the CA with default options.

The public property can be populated through many different means (a VBS, command-line, etc.) making it quite flexible.  The files will install to the location specified in the public property!