Tag: syndicated

  • Starting to Use Powershell

    I have to admit that before the Powershell Challenge, I wasn’t really looking forward to using Powershell for much of anything. It looked cumbersome, I didn’t always understand how sample scripts worked, and it was just easier to use the various other Windows tools to accomplish tasks.

    However as I’ve been working through the Challenge, I’ve started to gain some comfort with the language, conventions, help, etc. This came into play recently as I was beginning to set up a new domain for some testing and demos.

    I installed Server Core and went to configure a domain, which means static IP addresses and more. Once I had Core installed, with no domain and no other tools, I was slightly stuck. However I googled and when I found things like

    Get-NetAdapter

    and

    Set-NetIPAddress

    I wasn’t at all deterred. I could easily read and understand the way these commands work, how parameters are applied, how precedence matters with parens and piping works. Even a restart was quick with

    Restart-computer

    or

    stop-computer

    When I needed to verify which machine I was actually working on

    $env:computername

    was a quick way that worked well.

    The whole world of Powershell starts to look easier as I go along. The slow movement through the book has made me more likely to run a quick search and type a command than use the GUI for a number of server-level tasks that I’ve needed to do.

    It’s a neat new world for me.

  • Just use Version Control

    There are free systems out there. If you have no budget, and want to get started, download one of these:

    There are good ones to pay for as well, and some of them have other features and integration you may like:

    There are plenty more. Please, please, please, start using Version Control. There are compelling reasons from many successful developers, including those that want your database code under control.

    There are ways to do this, but please pick one. Version control is a must for professional software developers. That means if you write code, and get paid for it, use version control. If you write code, and don’t get paid for it, value your time and use VCS anyway.

  • Powershell in a Month Day 13 – Remote Control

    This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

    Remoting. It sounds complex, and intimidating. It isn’t, and it’s powerful. It’s also essential, allowing you to access commands on remove machines.

    The chapter starts with the idea of remoting, and running commands elsewhere. We learn this comes from telnet and other remote type access, and is implemented as a web services protocol, WS-MAN. Incidently, this is how SSMS works. Your T-SQL is executed remotely on the server, not on your workstation. Lots of people don’t get that and get confused.

    This chapter presents a challenge. You need a domain for security to work correctly, or easily, with remoting. There are potential workarounds, but it’s an issue. I haven’t had a domain at home because of overhead and not wanting a domain controller set up. That means some setup work to build a couple virtual machines and create a domain.

    Ugh. Annoying, but it’s something I should do. I have wanted to rebuild a domain for some time, but haven’t bothered, but this is the excuse to do so. As such, I read the chapter, and started setting up the domain. That will take a few days, so I’ll continue on with the next chapter as I get a domain ready. More notes to come once that’s done.

  • Powershell in a Month Day 12 – A Practical Interlude

    This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

    This chapter is a practical one. Build a scheduled task that removes all jobs from a certain printer. Not that hard, but we’re using Powershell, and I’ve never done this for sure.

    The chapter walks you through a process, though I’m not sure this is the best one. After all, building scheduled tasks from Powershell seems to be overkill, especially since I’ve rarely scheduled the same thing across multiple machines. Except SQL Agent, and there it’s certainly easy to use T-SQL to do so. However, I get the idea. They want you to work through looking for commands, and then figuring things out within Powershell.

    The other problem I have from this item is that there are typos. The command they first show with a parameter of “printer”, but that caused me errors. It needs to be “printername”. That threw me at first, and made me think if things didn’t work, I wouldn’t know where the errors were.

    As I worked along with the authors to create a task, trigger, action, etc. I felt somewhat empowered, but I also felt that they didn’t quite explain the details enough of how they delve into the commands. A lot of information is returned when you run help, and it can be confusing or difficult to choose which items to link and how. Overall, I felt they shortcut’ed the explanation a bit for people learning Powershell.

    However, the lab was similar. Create a folder and share it.

    I’ve done this lots of times, but not with PoSh. I knew that many of the DOS commands like “mkdir” work, but I wanted to find out what was the basis. A little help showed me this was the New-Item command. A few experiments and I had created a C:\Labs folder on my machine. I was thinking this would be a pipeline command, so I saved it.

    $cf = New-Item -path "c:\labs" -type "directory"

    When I saw the folder in Explorer, I felt a bit proud of myself.

    From there I dug into help with *share* and found the SMB share items. I’ve know that file sharing was with SMB, but I could certainly see some DBAs and others wondering. When I’ve used “SMB” in a few talks, I’ve gotten some blank stares at times. Anyway, I completed the task easily, and figured out I couldn’t pipeline these tasks. However, I had remembered somewhere in my mind that ($cf) would execute that variable, and that worked.

    Overall this was a good chapter and exercise. I could certainly see this lab being handy as I’ve often wanted to standardize things, like backup directories, on a lot of servers. I’ve even had standard shares at times.

    This was a good building block to learning how to assemble some commands and accomplish a task. I’d like to see 2-3 small tasks like this to help learn how to build to bigger projects. Perhaps that’s coming.