Archive for the ‘Windows 7’ Category

A cool ‘Remote Desktop Connection Manager’ tip!

April 4th, 2013 by Matthew Sharland | No Comments | Filed in Desktop OS, Microsoft, Virtual Desktop Management, Windows 7, Windows 8, Workstation Management

I am constantly monitoring multiple Microsoft Windows Servers and XP workstations via Remote Desktop Connection Manager and having to switch between each console one at a time is a very user-intensive and time-consuming process.  Though, I have recently discovered a very useful and time-saving trick that I will share with you below…

First, by default, the Remote Desktop Connection Manager gives you a thumbnail view of all of your workstations when you click on any “group” of servers from the left server pane list.  I always thought this was a “gimmick” and never thought twice about using it for anything because the dimensions of the thumbnail views of the remote desktops were just way too small to be useful.

But after reviewing the program’s options I found that you can modify the size of the thumbnails (Tools > Options > Client Area > Thumbnail Size)!

But that isn’t all!

The thumbnails are actual “live” clickable Remote Desktop sessions; so if you set the pixel size of the thumbnails to 25%, 30% or 40% of your screen size, you can fit 4-12 active server connections into one very productive window (obviously depending on your monitor size and screen resolution!).  This screen cap should give you a good idea of what I mean:

screenshot

 

I hope you find this tip as useful as I did!  Enjoy!

 

 

Did you like this? Share it:

Tags: , , ,

Scripted Home Folder Management with PowerShell Pt. 6 – The Script!

October 4th, 2012 by Jeremy Pavlov | No Comments | Filed in Microsoft, PowerShell, Scripting, Windows 7

This is the last post in my series on scripting user and Home Folder management (see Part 1, Part 2, Part 3, and Part 4 and Part 5 for reference) — it was a lot of ground to cover, but we did it!  Thanks for hanging in there with me.  We’ve created the user and attributes, built the folder, set permissions, added the Home Folder attribute on the user object; all with PowerShell.  You don’t get much more real-world than that!

Now, as promised, it’s time to pull it all together into one example script.

Of course, now that we’re putting all the concepts from the previous posts together, we need to be smart and add a few smart/standard script things; like good use of variables, error checking, and so forth.  Specifically, the new things I’m introducing in this post are:

  • Use of variables  – To make the script portable and easily modifiable
  • Use of command line arguments – To accept the new user’s name as input arguments
  • Use of SubString – To generate a “UserName” (a.k.a. SamAccountName) from a first and last name
  • Check for pre-existing – To make sure we don’t attempt to create an already-existing user name

All of the items above are in the first section of the script below, and the remaining sections are where I pull in the concepts from the previous posts to get it all done.  I don’t want to go into great detail on these new items, but they are necessary to make the script flow correctly and be usable right away as-is.

So, here you go.  You can paste this right into a file (something like provisionNewUser.ps1), launch a PowerShell session, and run it with the new user’s First Name and Last Name on the command line (as explained early in the body of the script). 

And here’s my warning: Don’t ever do what people on the Internet tell you to do; if this script is scary to you, don’t run it.  In fact, only run this in a test lab, until you are comfortable with the specifics.  So there.

# Home Folder Provisioning Demo Script
# Jeremy Pavlov, Coretek Services, 20121003
#
# Execute in a powershell session, with the new user's First and Last names after the command, like this:
# .\provisionNewUser.ps1 Jeremy Pavlov
# # Make sure you run this if not already loaded, for AD-based commands Import-Module ActiveDirectory # # Read in the first name and last name from command line inputs $FirstName = $args[0] $FirstInitial = $FirstName.Substring(0,1) $LastName = $args[1] $LastInitial = $LastName.Substring(0,1) $UserName = "$FirstInitial$LastName" $MyDomain = "CoretekServices.local" $HomePrefix = "\\$MyDomain\Corp\Homes" $DefaultUserOu = "ou=New Users,dc=CoretekServices,dc=local" # write "First name will be: $FirstName" write "Last name will be: $LastName" write "User name will be: $UserName" write "Home Folder will be: $HomePrefix\$LastInitial\$UserName" write "" # # See if the user exists $CheckUser = Get-ADUser -ldapFilter "(SamAccountName=$UserName)" # #If user exists, exit! if ($CheckUser -ne $Null) { write "User $UserName already exists! Exiting..." write "" exit } # write "Creating $UserName..." write "" New-ADUser -Path "$DefaultUserOu" -SamAccountName "$UserName" -Enabled $true -Name "$FirstName $LastName" -GivenName "$FirstName" -Surname "$LastName" -AccountPassword (ConvertTo-SecureString –AsPlaintext "ChangeMe123!" –Force) -ChangePasswordAtLogon $true # write "Create $HomePrefix\$LastInitial\$UserName ..." write "" New-Item -type directory -path $HomePrefix\$LastInitial\$UserName # write "Setting permissions on the $HomePrefix\$LastInitial\$UserName ..." write "" $acl = Get-Acl $HomePrefix\$LastInitial\$UserName $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$MyDomain\$UserName", "DeleteSubdirectoriesAndFiles, Modify, Synchronize", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.AddAccessRule($rule) Set-Acl $HomePrefix\$LastInitial\$UserName $acl # write "Setting the Home Folder attribute for $UserName" write "" Set-ADUser -identity "$UserName" -homeDrive h: -homeDir "$HomePrefix\$LastInitial\$UserName" # write "...Complete!" write "" #

…and there you have it.  Now, of course, I could have dumped in a lot of other good practice stuff like input validations and things, or other additional neat features, but I’m only trying to demonstrate the core concepts here from our previous posts in this series.  I don’t want to over-whelm the example and make it difficult or — heaven forbid — boring (gasp!) to read.

But please, if you have a better way of doing it, make sure to drop a comment or two and help out others…

Now go create some users!

 

 

Did you like this? Share it:

Tags: , , , , , , , ,

Scripted Home Folder Management with PowerShell Pt. 5

September 27th, 2012 by Jeremy Pavlov | No Comments | Filed in Microsoft, PowerShell, Scripting, Windows 7

In my last post in this series on scripting user management (see Part 1, Part 2, Part 3, and Part 4 for reference), I left off with a couple different ways to set the Home Folder attribute, using DSMod or PowerShell.

But I thought it was important to spend a moment and stress that when you’re scripting these changes, it’s all about what you *have* available to use as the basis of your queries and changes.  What I mean is this:  If you only have the samAccountName (often called the User ID), you make the query/change one way; but if you have the CN (known as the User Name), then you do it another way.  Let me show you some examples…

DSMod

As shown in Part 4, if you have the CN — as DSMod requires — you can just make the call directly:

dsmod user "cn=Jeremy Pavlov,ou=Demo,dc=CoretekServices,dc=local" -hmdrv H: -hmdir "\\MyCompany.org\DFSPath\Homes\$username$"

But what if you don’t know the CN, and all you have is the samAccountName?  Then in this case, you must use the samAccountName to first *get* the CN, then pipe the CN through to the DSMod command like this:

dsquery user -samid "JPavlov" | dsmod user -hmdrv H: -hmdir "\\MyCompany.org\DFSPath\Homes\$username$"

In the above example, we’re using dsquery to simply retrieve the samAccountName, as represented by the samid flag; which returns a perfectly-formatted CN that is used as input for the DSMod.  The bottom line is that you can make the change no matter which format you have the User name!

PowerShell

On the PowerShell side of things, you have a similar flexibility.  The PowerShell example I used in Part 4 utilized the samAccountName (as represented by the -identity flag) instead of the CN, like this:

Set-ADUser -identity "jpavlov" -homeDrive h: -homeDir "\\MyCompany.org\DFSPath\Homes\jpavlov"

But if you only have the CN to start with, then we have to go fishing.  We need to do a Get-ADUser with the -like option, and stuff it in a variable, prune that variable down to just what we want, and then pass it on to the Set-ADUser command.  Here’s one example how to get it done, like this:

$Dude = Get-ADUser -Filter 'Name -like "Jeremy Pavlov"'
$DudeSamId = $Dude.SamAccountName
Set-ADUser -identity $DudeSamId -homeDrive h: -homeDir "\\MyCompany.org\DFSPath\Homes\$DudeSamId"

And with that, we’ll press pause, until next time…

Next time…  Let’s wrap this scripting up…  See you then!

Did you like this? Share it:

Tags: , , ,

Scripted Home Folder Management with PowerShell Pt. 4

September 20th, 2012 by Jeremy Pavlov | No Comments | Filed in Microsoft, PowerShell, Scripting, Windows 7

If you’ve been following along in this post series (see Part 1, Part 2, and Part 3 of this series for reference), where I showed you how to create AD users, create soon-to-be Home Folders, and set permissions; all with PowerShell (and some other tools). 

Now, it’s time to stitch it all together by assigning the Home Folder attribute on our user object, and point the attribute to the folder we’ve prepared.  Yes, of course you could just set the Home folder “Connect To” options on the Profile tab of a User object in the Active Directory Users and Computers (ADUC) tool, but that’s not the point.  We want scripting!

So to pick up where we left off last time, all we really need to do is provide a Home folder attribute update on an existing user object.  Of course, we could have done this upon initial creation, but this series of posts is attempting to demonstrate the individual steps that you might encounter in the real world enterprise; either separately or together. 

There are various tools and ways to make our changes, including via the old method outlined in Part 1.  But I’d be remiss if I didn’t confess that much of the time I use good ol’ DSMod.  Here’s what a DSMod line would look like to update our user:

dsmod user "cn=Jeremy Pavlov,ou=Demo,dc=CoretekServices,dc=local" -hmdrv H: -hmdir "\\MyCompany.org\DFSPath\Homes\$username$"

…note that I used “$” (dollar sign), which is a cool way to have the DSMod command utilize the “Windows 2000 User Name”, or the “samAccountName” as the value for this special variable.

*Aside: Why do I keep mentioning the DSMod / DSAdd methods?  I’ll tell you.  It’s because much of the time, I use scripting to parse certain inputs and then generate other scripts that I can hand out to other administrators (yes, script-generating scripts).  And while I can’t be certain that everyone will be familiar with script editing and the PowerShell modules for Active Directory, I can be pretty sure they’ll have a command prompt and DSMod.  There are other reasons, but the rest mostly come down to preference and how the result files look, etc.  So there you go.

However, the new Powershell method with the ActiveDirectory module is pretty nice and easy for this task, too.  Here is the PowerShell equivalent to the DSMod command above: 

set-aduser -identity "jpavlov" -homeDrive h: -homeDir "\\MyCompany.org\DFSPath\Homes\jpavlov"

…or at least its close, although this time I used the “ID” instead of the “Name”.  I think this deserves some closer examination…  So next week, I’ll spend a some time covering alternative inputs/methods to the above, before we move on to troubleshooting and validation, and then sum the whole thing up.

Next time…  A couple more ways to to get it done…  See you then!

 

Updated 20120923:  command syntax fix

Did you like this? Share it:

Tags: , , , ,

Scripted Home Folder Management with PowerShell Pt. 3

September 13th, 2012 by Jeremy Pavlov | 2 Comments | Filed in Microsoft, PowerShell, Scripting, Windows 7

In this post, I’m following up on Part 1 and Part 2 of this series where I showed you how to create users (and set a few attributes) with PowerShell.  Now that you have your user created and configured, I’m going to show you a bit about Home Folder creation and permission assignment.  Remember that all of these basics are leading toward a single, simplified, scripted elements method of managing Home Folders in the Enterprise.

So let’s create a folder.  Of course, you know how to do that already, so I won’t belabor the point too much.  Picking up where we left off in the last post, you already have a PowerShell session going, with network access to the shares where the folders will be created.  And since PowerShell has native access to the filesystem via its own object paths, you can actually skip the fancy stuff and just do a good ol’ md:

md \\server\Share$\JPavlov

…or if you’re using a DFS structure, something like this…

md \\MyCompany.org\DFSPath\Homes\JPavlov

I know, I know.  That’s not PowerShell.  So if you really want to use the benefit of PowerShell, you would use the New-Item command like this (sticking with our DFS structure from above):

New-Item -type directory -path \\MyCompany.org\DFSPath\Homes\JPavlov

Okay, great.  At this point, we have a folder, but no permissions yet for the person who will use it.  In order to set the permissions, we’ll stick with PowerShell and…

1.) Build a variable with the existing permissions with the Get-Acl command:

$acl = Get-Acl \\MyCompany.org\DFSPath\Homes\JPavlov

2.) Add-on the permission we want (your permissions may vary!):

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("CoretekServices\JPavlov", "DeleteSubdirectoriesAndFiles, Modify, Synchronize", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)

3.) And then stuff it all back on the folder with the Set-Acl command:

Set-Acl \\MyCompany.org\DFSPath\Homes\JPavlov $acl

There you have it!  We’ve created the soon-to-be Home Folder for the user we created previously, and added permission we want.  So it’s out there if the user can browse around and find it…  But let’s help them out a little bit and deliver it as a mapped drive in the next post.

Next time…  Assigning this folder as the user’s Home Folder via the AD attribute.  See you then!

 

 

Did you like this? Share it:

Tags: , , , , , , , , , ,

Scripted Home Folder Management with PowerShell Pt. 2

September 6th, 2012 by Jeremy Pavlov | No Comments | Filed in Microsoft, PowerShell, Scripting, Windows 7

In this post, I’m following up on Part 1 of this series where I showed you how to create users (and set a few attributes) the basic way with Powershell.  Now, I’m going to show you an easier way to create users thanks to the new(ish) Powershell modules that came along in Windows Server 2008 R2.  In the up-coming parts of this series, we’ll continue on to Home Folder creation/management concepts and automation.  But for now, let’s get that user created…

To be honest with you, I have to admit that most of the time when I’m building a script loop and just need an easy output that looks nice, I’d just do the DSAdd tool like this:

dsadd user "cn=Jeremy Pavlov,ou=Demo,dc=CoretekServices,dc=local" -samId JPavlov -disabled no -fn Jeremy -ln Pavlov -pwd ChangeMe123! -mustchpwd yes

…but the future is here, and the future is PowerShell; and you and I have to get over it.  Powershell gives us better portability, variable management, etc., etc…  So onward and upward. 

And with recent versions of Windows 2008 R2, Microsoft provides the new “ActiveDirectory” module; making user creation/management activities as easy to do as the DSAdd/DSMod tools.  Here’s what I mean…

Open a Powershell session, and import the ActiveDirectory module like this:

Import-Module ActiveDirectory

Note: You need to have network access to an Active Directory server running AD Web Services for this module to work. 

Loading this module is the equivalent of launching the “Active Directory Module for Windows PowerShell” option on Windows 7 and Server 2008, but if you’re scripting you’ll want to make sure you load the module explicitly.  And, as a result, you have a ton of new AD tools available to you. 

You can get a good look at the majority of the new AD tools by using this command:

Get-Command *-AD*

Finally, using the New-ADUser command, we create that user with what is pretty much the equivalent of the DSAdd above (I used the same options to help clarify):

New-ADUser -Path "ou=Demo,dc=CoretekServices,dc=local" -SamAccountName "JPavlov" -Enabled $true -Name "Jeremy Pavlov" -GivenName "Jeremy" -Surname "Pavlov" -AccountPassword (ConvertTo-SecureString –AsPlaintext "ChangeMe123!" –Force) -ChangePasswordAtLogon $true

And that’s it!  You have a new user with your standard attributes set correctly.  I like this one-line method because it looks much cleaner when you are building import scripts that must be distributed to other folks, or when you want to insert some other command between each line (if you’re looping), etc.; it’s neat.

On a side note, there’s also a way to read in the contents of a formatted CSV, and pump it into the New-ADUser command; but my goal here is to show you concepts that ultimately can be combined into an multifaceted script.

Next time…  Home Folder creation and permission assignment.  See you then!

 

 

Did you like this? Share it:

Tags: , , , , , , , ,

Scripted Home Folder Management with PowerShell Pt. 1

August 30th, 2012 by Jeremy Pavlov | No Comments | Filed in PowerShell, Scripting, Windows 7

I’ve been doing tons of scripting for the project on which I’m working lately.  And I thought it’d be cool to spend a few posts in a row covering a few base elements of PowerShell-based user and Home Folder management, and build up toward a script for user and folder creation/deletion that you can easily use. 

I don’t intend to get fancy with this; in fact, I intend to make is simple as possible, and maybe kick around a few alternative methods to do the same tasks.  My goal is not to teach PowerShell, but to show you you can script these things easily.

So join me on the journey!  But let’s get there in small steps.  We’ll start at the start, with user creation.  Open a PowerShell session, and let’s get to it…

In order for this article series to work, I have to make some assumptions: I’ll assume you have the proper rights, a test environment, the proper PowerShell modules, and a Windows 7 or Server 2008 R2 computer.

For this first method in Part 1, we are going to show you how to do it with just native Powershell, using the ADSI provider, without any additional Powershell modules.  It’s like learning how to do the work on paper before you use a calculator…  ;)

First, set up a variable that opens an LDAP connection to the server, using the ADSI provider (note, “LDAP” is case-sensitive) and specifying the OU where we’ll be creating our new User object:

$MyConnection = [ADSI]"LDAP://ou=Demo,dc=CoretekServices,dc=local"

Next, set up a variable that defines what you’re creating, along with a few critical attributes:

$MyObject = $MyConnection.create("User","cn=Jeremy Pavlov") 
$MyObject.Put("givenName","Jeremy")
$MyObject.Put("surname","Pavlov")
$MyObject.Put("samAccountName","JPavlov")

Finally, the command to make it happen:

$MyObject.SetInfo()

…and with that, the user is created in a “disabled” state.  So let’s fix that and set a password, using the same object and connection calls:

$MyObject.PsBase.Invoke("SetPassword","ChangeMe123!")
$MyObject.PsBase.InvokeSet("AccountDisabled","$false")
$MyObject.SetInfo()

But, as you may or may not expect, the act of setting the password in the previous step also clears the requirement for the user to change the password at first login… but we definitely want the user to do that.  So let’s set it back with one final step:

$MyObject.pwdLastSet = 0
$MyObject.SetInfo()

Okay, okay, I know what you’re saying, “…Man, that’s alot of work…”  And I’ll admit,this is the hard way.  So I’ll show you some easier ways in the next post.

(Updated 20120903; fixed syntax typos, split some content to next week’s post)

Next time…  A couple easier creation options…  See you then!

 

 

Did you like this? Share it:

Tags: , , , ,

How to import the HKCU values of a different profile into your registry…

August 2nd, 2012 by Paul Opper | No Comments | Filed in Application Packaging, Computer Support, Desktop Management, Desktop OS, Microsoft, Uncategorized, Windows 7

When troubleshooting an application installation issue — or an issue with the application itself — on the Windows operating system, it’s often necessary to view the registry.  The Windows registry holds a wealth of information and settings that determine just about everything related to how Windows operates; what it looks like, where and what users can access, and how applications behave.  If you know where to look, or what you’re looking for, this can be a pretty easy task; the “Find” function in the Registry Editor works pretty well.  However, if the issue is with registry keys under the HKEY_CURRENT_USER (HKCU) hive, it can be a challenge.  You see, the keys under the HKCU hive are unique to each users profile; thus, when you view the registry keys under HKCU in the Registry Editor, you are viewing the keys of the current logged-in user profile.

In an enterprise environment, applications are typically distributed via a configuration/distribution system such as Novell ZENworks Configuration Mannager (ZCM) or Microsoft System Center Configuration Manager (SCCM).  When software is installed through these systems, the application installers can be configured to run as the logged on user, under the system profile, or even as a “dynamic” administrator.  If the installer writes values to the HKCU profile they are written to the profile that ran the installer.  Thus, there is often need to view the HKCU values of a different user profile.  Adding more complexity to this, you may find yourself in a situation where the user profile under which the HKCU values are located doesn’t have access to the Registry Editor.  In this situation, you need to import the profile’s HKCU hive into your registry so you can view it.

The HKCU values for a profile are stored in a file called ntuser.dat, located in the root of the users’ profile.  On Windows 7 the path is c:\users\(profile)\ntuser.dat.  There are a few ways to import the ntuser.dat into the registry with Registry Editor, but the quickest and easiest way I’ve found to do this is using the following command from an elevated command prompt:

reg.exe load HKLM\TempHive c:\users\(profile)\ntuser.dat

Now the HKCU values of the profile you imported can be viewed under a key called “TempHive” in the HKEY_LOCAL_MACHINE hive.

Hopefully, this will help you to resolve that issue you’re looking into!

 

Did you like this? Share it:

How to script “Ownership” of NTFS File Systems…

July 26th, 2012 by Matthew Sharland | No Comments | Filed in Microsoft, Microsoft Infrastructure, Scripting, Server Migration, Windows 7

There’s a time in every IT professional’s life where he or she will need to “Take Ownership” of files and folders that reside on an NTFS File Server (or in larger cases with hundreds or thousands of servers) in a Windows Server 2008 R2 or Windows 7 environment.  I’m sure most IT professionals already know how to do this in the Windows Explorer GUI … but what if your task at hand required that you script this process to run during a limited window of time given during a server migration, and you had to minimize the amount of “clicks” as well as the amount of time spent on multiple servers?  

I was recently assigned to a project very similar to the scenario described above; and after a little research, I stumbled upon a little-known Microsoft tool called ‘takeown.exe’ that has been shipping with Microsoft Server products since Windows Server 2003.  Within minutes of discovering ‘takeown.exe’ I had a script written and I was running it in my test environment with positive results.  This shows how simple the tool really is!

Below is the usage example as seen from the command line ‘takeown.exe /?’:

TAKEOWN [/S system [/U username [/P [password]]]] /F filename [/A] [/R [/D prompt]]

Below is my personally recommended example: 

TAKEOWN.exe /F C:\MyFolder /R /A

 

As expressed above, my suggestions are to use the /F (to specify the folder to apply ownership on), the /R switch (as in “recursive” which mean to apply to all child objects, sub-folders and files) and the /A switch (which gives ownership to the “Administrators” group instead of the currently logged in user).  And while I didn’t use the /D switch in the above example, it may be necessary to use the “/D Y” to avoid being prompted in cases where the user ID running the command does not have rights to list the folders.   

You can also reference additional parameters by typing in ‘takeown.exe /?’ from the command prompt on any Windows Server 2008 R2 server or Windows 7 machine.

 

Did you like this? Share it:

Tags: , , ,

Send an Email from the Windows Commmand Prompt or Script…

July 19th, 2012 by Jeremy Pavlov | No Comments | Filed in Microsoft, Scripting, Windows 7

Today, Avi and I were discussing one of the requirements of an application he’s working on;  it seemed simple enough at first blush…

He needed to send an email from a Windows 7 computer — which is fairly straightforward if you happen to have something like BLAT installed, or if you’re able to script a call to a nearby SMTP gateway.  However, there was one major requirement this time:  it had to appear to come from the *user* of the application, with the user’s intent/blessing/permission. 

Yes, Avi could have configured the application to make a direct call to the local email client executable — if there were guaranteed to be one (not necessarily the case), and if the version/type were to be predictable (it might be Outlook, it might be GroupWise, etc.) to properly call with the correct options and flags.  Avi did some digging and soon found a way to get a fully formatted message to launch in Outlook, but we had to modify it a tad to get it to work in both GroupWise and Outlook (and perhaps others).  Here’s what we settled on, and how it works…

Aside: I’ll have to assume that your GroupWise or Outlook is properly installed and configured for these things to work.

Let’s start with the basics (pun intended); this should launch your email client and pre-populate the recipient (interestingly, it should work no matter whether your email client is configured or not):

start mailto:sales@CoretekServices.com

…but you knew that, and you’re clearly not impressed.  Now perhaps the trickiest part: after the recipient in the command — and before the next component (I use Subject in this example) — it is best to use a question (?) mark here for Outlook *and* GroupWise compatibility, although a caret+ampersand (^&) will work if using Outlook only (note that the “%20” is a space character):

start mailto:sales@CoretekServices.com?Subject=Your%20Subject...

…and now you’re intrigued.  Let’s build on that.  Next, we tack on another option in the command (I show the CC option here), separated with a caret+ampersand (^&) :

start mailto:sales@CoretekServices.com?Subject=Your%20Subject...^&CC=questions@YourLinuxGuy.com

…and now I’ve won you over.  Cool!  Let’s complete the line — separated by more caret+ampersand (^&) characters, of course — and make it a fully populated email, ready-to-send:

start mailto:sales@CoretekServices.com?Subject=Your%20Subject...^&CC=careers@CoretekServices.com^&BCC=secret@CoretekServices.com^&Body=This%20is%20the%20message,%20which%20I%20agree%20to%20send%20by%20clicking%20SEND.

Now click send, and enjoy!

 

 

Did you like this? Share it:

Tags: , , , , , ,