1
00:00:00,940 --> 00:00:03,720
Way back in version 1 of PowerShell, it

2
00:00:03,720 --> 00:00:06,130
was possible for individuals or companies

3
00:00:06,130 --> 00:00:08,140
to use an object known as a PowerShell

4
00:00:08,140 --> 00:00:11,040
snap‑in to extend PowerShell by importing

5
00:00:11,040 --> 00:00:13,140
additional commands, above and beyond

6
00:00:13,140 --> 00:00:15,650
those that are included by default. I

7
00:00:15,650 --> 00:00:18,110
mention snap‑ins briefly, only because you

8
00:00:18,110 --> 00:00:20,440
still may come across them, especially in

9
00:00:20,440 --> 00:00:23,690
articles or blogs online. Snap‑ins were

10
00:00:23,690 --> 00:00:26,040
pretty clunky as they had to be installed

11
00:00:26,040 --> 00:00:28,330
and registered on each individual machine,

12
00:00:28,330 --> 00:00:31,330
usually by running an executable file, and

13
00:00:31,330 --> 00:00:33,110
they added information into the Windows

14
00:00:33,110 --> 00:00:36,140
Registry. They also lacked the ability to

15
00:00:36,140 --> 00:00:39,130
define things like dependencies. In short,

16
00:00:39,130 --> 00:00:41,460
PowerShell snap‑ins are the very old way

17
00:00:41,460 --> 00:00:43,870
of doing things. And look, you really

18
00:00:43,870 --> 00:00:46,010
shouldn't come across them anymore, but if

19
00:00:46,010 --> 00:00:48,150
you do, it might be worth a polite mention

20
00:00:48,150 --> 00:00:50,060
to the author to look at releasing their

21
00:00:50,060 --> 00:00:52,870
commands in a PowerShell module. The

22
00:00:52,870 --> 00:00:54,770
preferred packaging method nowadays for

23
00:00:54,770 --> 00:00:57,130
PowerShell commands is, and has been for

24
00:00:57,130 --> 00:00:59,510
quite some time, by using a PowerShell

25
00:00:59,510 --> 00:01:03,040
module. A module is almost always just a

26
00:01:03,040 --> 00:01:05,390
set of files. They are typically script

27
00:01:05,390 --> 00:01:07,430
files, but sometimes you'll come across

28
00:01:07,430 --> 00:01:10,130
modules that are binary DLLs, and often

29
00:01:10,130 --> 00:01:12,740
these come from vendors such as Microsoft.

30
00:01:12,740 --> 00:01:14,490
You still treat both of these types the

31
00:01:14,490 --> 00:01:16,790
same way from an installation and usage

32
00:01:16,790 --> 00:01:18,990
perspective. And unless you're building

33
00:01:18,990 --> 00:01:20,970
modules, which is not in the scope of this

34
00:01:20,970 --> 00:01:23,110
course, you should just be aware of this,

35
00:01:23,110 --> 00:01:25,500
but not too concerned with it. The main

36
00:01:25,500 --> 00:01:28,050
purpose of a module is to allow the reuse

37
00:01:28,050 --> 00:01:30,970
and abstraction of PowerShell code. Simply

38
00:01:30,970 --> 00:01:33,380
put, a module is a package of related

39
00:01:33,380 --> 00:01:35,820
PowerShell functions or commands grouped

40
00:01:35,820 --> 00:01:38,600
together as a single unit, usually saved

41
00:01:38,600 --> 00:01:41,410
in a single directory. There are a number

42
00:01:41,410 --> 00:01:42,680
of PowerShell modules that are

43
00:01:42,680 --> 00:01:45,140
pre‑installed on a Windows machine, and

44
00:01:45,140 --> 00:01:46,880
these are sometimes referred to as the

45
00:01:46,880 --> 00:01:49,790
core modules. Typically on a Windows

46
00:01:49,790 --> 00:01:52,020
computer, if features included with the

47
00:01:52,020 --> 00:01:54,020
operating system have commands to manage

48
00:01:54,020 --> 00:01:56,080
them, then those PowerShell modules are

49
00:01:56,080 --> 00:01:58,640
also pre‑installed. Commands within a

50
00:01:58,640 --> 00:02:01,530
module are most often all related to a

51
00:02:01,530 --> 00:02:04,050
specific service or system, and each

52
00:02:04,050 --> 00:02:06,210
command should perform one specific

53
00:02:06,210 --> 00:02:08,600
function, and it should do that one thing

54
00:02:08,600 --> 00:02:11,650
really well. For example, there's a

55
00:02:11,650 --> 00:02:13,310
component of Windows known as the

56
00:02:13,310 --> 00:02:15,500
Background Intelligent Transfer Service,

57
00:02:15,500 --> 00:02:17,970
or BITS for short, and there's a

58
00:02:17,970 --> 00:02:20,410
PowerShell module provided by Microsoft

59
00:02:20,410 --> 00:02:23,370
named BitsTransfer. This module includes

60
00:02:23,370 --> 00:02:25,660
commands such as Get‑BitsTransfer,

61
00:02:25,660 --> 00:02:28,360
Remove‑BitsTransfer, Set‑BitsTransfer,

62
00:02:28,360 --> 00:02:31,410
Start‑BitsTransfer, you get the idea. This

63
00:02:31,410 --> 00:02:33,480
module doesn't include any commands to do

64
00:02:33,480 --> 00:02:35,970
with any other system or platform. All of

65
00:02:35,970 --> 00:02:37,910
the commands are related to managing the

66
00:02:37,910 --> 00:02:40,570
same thing. The author for this module

67
00:02:40,570 --> 00:02:42,060
would have started by creating each

68
00:02:42,060 --> 00:02:44,360
particular command to perform a specific

69
00:02:44,360 --> 00:02:46,690
function. And then they got to a point

70
00:02:46,690 --> 00:02:48,300
where they had separate commands to do

71
00:02:48,300 --> 00:02:51,710
separate tasks, all related to BITS. From

72
00:02:51,710 --> 00:02:53,840
there, it makes sense to package these

73
00:02:53,840 --> 00:02:56,110
commands in a single unit, which is where

74
00:02:56,110 --> 00:02:58,820
a PowerShell module is formed. From the

75
00:02:58,820 --> 00:03:00,730
perspective of an author of PowerShell

76
00:03:00,730 --> 00:03:03,440
code, packaging commands in a module makes

77
00:03:03,440 --> 00:03:05,550
it really easy to include information

78
00:03:05,550 --> 00:03:07,840
about the module and add in properties

79
00:03:07,840 --> 00:03:09,900
like dependencies, versioning, and the

80
00:03:09,900 --> 00:03:12,120
requirements while also being able to

81
00:03:12,120 --> 00:03:14,400
publish the module to a repository like

82
00:03:14,400 --> 00:03:16,260
the PowerShell Gallery, making it

83
00:03:16,260 --> 00:03:18,060
instantly available to millions of

84
00:03:18,060 --> 00:03:21,170
PowerShell users. All you need to do to

85
00:03:21,170 --> 00:03:23,820
install or deploy a module is place the

86
00:03:23,820 --> 00:03:25,660
package of files in one of several

87
00:03:25,660 --> 00:03:27,730
particular folders that PowerShell knows

88
00:03:27,730 --> 00:03:30,350
to search in. These folders are stored in

89
00:03:30,350 --> 00:03:32,090
an environment variable named

90
00:03:32,090 --> 00:03:35,050
PSModulePath, and I'll show this to you in

91
00:03:35,050 --> 00:03:37,480
the upcoming demo. You'll want to become

92
00:03:37,480 --> 00:03:40,790
very familiar and aware of PSModulePath as

93
00:03:40,790 --> 00:03:43,150
PowerShell uses this variable to locate

94
00:03:43,150 --> 00:03:45,540
modules when you don't specify the full

95
00:03:45,540 --> 00:03:48,650
path to a module. Now, strictly speaking,

96
00:03:48,650 --> 00:03:50,940
you don't need to place a module in one of

97
00:03:50,940 --> 00:03:53,710
the PSModulePaths to use it. You could put

98
00:03:53,710 --> 00:03:55,720
it anywhere in the file system and then

99
00:03:55,720 --> 00:03:57,670
import the module into your PowerShell

100
00:03:57,670 --> 00:03:59,560
console by using the command named

101
00:03:59,560 --> 00:04:02,340
Import‑Module. But for the most part,

102
00:04:02,340 --> 00:04:04,050
you're better off by using one of these

103
00:04:04,050 --> 00:04:06,240
paths, and you'll see the power of that in

104
00:04:06,240 --> 00:04:09,070
the demo. While you can just copy and

105
00:04:09,070 --> 00:04:10,820
paste a folder containing a PowerShell

106
00:04:10,820 --> 00:04:13,520
module onto your computer and start using

107
00:04:13,520 --> 00:04:16,380
it, there are built‑in commands we can use

108
00:04:16,380 --> 00:04:18,530
to help with finding, installing, and

109
00:04:18,530 --> 00:04:20,440
managing modules, and I'll take you

110
00:04:20,440 --> 00:04:22,790
through those in detail in the next module

111
00:04:22,790 --> 00:04:25,830
in this course. There's one last thing I'd

112
00:04:25,830 --> 00:04:27,730
like to cover before we jump into a few

113
00:04:27,730 --> 00:04:30,820
demos here. Starting from version 3,

114
00:04:30,820 --> 00:04:32,990
PowerShell has the ability to import

115
00:04:32,990 --> 00:04:35,790
modules into your console automatically

116
00:04:35,790 --> 00:04:38,790
from any of those PSModulePaths, if you

117
00:04:38,790 --> 00:04:40,870
run any command from a module that's

118
00:04:40,870 --> 00:04:43,670
installed on your machine. This is known

119
00:04:43,670 --> 00:04:46,850
as module auto‑loading. While auto‑loading

120
00:04:46,850 --> 00:04:49,290
is a fantastic feature, using the

121
00:04:49,290 --> 00:04:51,790
Import‑Module command to explicitly import

122
00:04:51,790 --> 00:04:53,980
a module does have some benefits and use

123
00:04:53,980 --> 00:04:56,190
cases, and you should be familiar with

124
00:04:56,190 --> 00:04:58,750
this command. Some scenarios where you may

125
00:04:58,750 --> 00:05:00,990
want to use Import‑Module, rather than

126
00:05:00,990 --> 00:05:03,400
relying on the auto‑load, are if the

127
00:05:03,400 --> 00:05:05,040
module is not in one of those default

128
00:05:05,040 --> 00:05:07,370
PSModule folders. You'll need to run

129
00:05:07,370 --> 00:05:09,720
Import‑Module and point it to the specific

130
00:05:09,720 --> 00:05:12,610
path of the module. Occasionally you will

131
00:05:12,610 --> 00:05:14,820
come across circumstances where you have

132
00:05:14,820 --> 00:05:16,890
multiple modules that contain conflicting

133
00:05:16,890 --> 00:05:19,540
command names. An example of this is

134
00:05:19,540 --> 00:05:22,270
Get‑VM, which is a common command in the

135
00:05:22,270 --> 00:05:25,050
VMware PowerCLI module, as well as the

136
00:05:25,050 --> 00:05:27,850
Microsoft Hyper‑V module. By using

137
00:05:27,850 --> 00:05:30,260
Import‑Module, you can use a parameter

138
00:05:30,260 --> 00:05:32,920
named NoClobber, which will not import

139
00:05:32,920 --> 00:05:34,890
commands that have the same names as

140
00:05:34,890 --> 00:05:37,640
existing commands in the current session.

141
00:05:37,640 --> 00:05:39,860
Another way of tackling this problem is to

142
00:05:39,860 --> 00:05:42,940
use the prefix parameter of Import‑Module.

143
00:05:42,940 --> 00:05:45,430
So using the example from before, when we

144
00:05:45,430 --> 00:05:47,900
had a conflicting command of Get‑VM, you

145
00:05:47,900 --> 00:05:49,730
might import the VMware module with a

146
00:05:49,730 --> 00:05:52,880
prefix of VMW, meaning that all commands

147
00:05:52,880 --> 00:05:55,990
from that module will have a VMW prefix.

148
00:05:55,990 --> 00:05:58,700
So Get‑VM can be used for the Hyper‑V

149
00:05:58,700 --> 00:06:05,000
command, while Get‑VMW VM can be used for the VMware command.