Tag: Window

Managing Windows Networking with cmdlets

At the heart of every organization is the network‚ÄĒthe infrastructure that enables client and server systems to interoperate. Windows has included networking features since the early days of Windows for Workgroups 3.1 (and earlier with Microsoft LAN Manager).

Many of the tools that IT pros use today have been around for a long time, but have more recently been replaced by PowerShell cmdlets. In this article, we look at some of the old commands and their replacement cmdlets.

New ways to do old things

Networking IT pros in the Windows Server space have been using a number of console applications to perform basic diagnostics for decades. Tools such as Ipconfig, Tracert, and NSlookup are used by IT pros all over the world. The network shell (netsh) is another veritable Swiss Army Knife set of tools to configure and manage Windows networking components.

PowerShell implements a number of cmdlets that do some of the tasks that older Win32 console applications provided. Cmdlets, such as Get-NetIPConfiguration and Resolve-DnsName, are newer alternatives to ipconfig.exe and nslookup.exe.

These cmdlets also add useful functionality. For example, using Test-NetConnection enables you to check whether a host that might block ICMP is supporting inbound traffic on a particular port. ping.exe only uses ICMP, which may be blocked somewhere in the path to the server.

One administrative benefit of using cmdlets rather than older console applications relates to remoting security. With JEA, you can constrain a user to only be able to use certain cmdlets and parameter values. In general, cmdlets make it easier for you to secure servers that are open for remoting.

This article shows you some of the new cmdlets that are available with PowerShell and Windows Server 2019.

Getting ready

This recipe uses two servers: DC1.Reskit.Org and SRV1.Reskit.Org. DC1 is a domain controller in the Reskit.Org domain and SRV1 is a member server. This article assumes that you have already set up DC1 as a domain controller. Run this exercise on SRV1.

How to do it…

  • Examine two ways to retrieve the IP address configuration (ipconfig versus a new cmdlet):
  • Ping a computer:
  • Use the sharing folder from DC1:
  • Share a folder from SRV1:
  • Display the contents of the DNS client cache:
  • Clear the DNS client cache using old and new methods:
  • Perform DNS lookups:

How it works…

In step 1, you examined the old/new way to view the IP configuration of a Windows host using ipconfig.exe and the Get-NetIPConfiguration cmdlet. First, you looked at two variations of using ipconfig.exe, which looks like this:

The Get-NetIPConfiguration cmdlet returns similar information, as follows:

In step 2, you examined the ping.exe command and the newer Test-NetConnection cmdlet. Using these two commands to ping DC1 (from SRV1) looks like this:

The Test-NetConnection cmdlet is also able to do some things that ping.exe cannot do, including testing access to a specific port (as opposed to just using ICMP) on the target host and providing more detailed information about connecting to that remote port, as you can see here:

In step 3, you examined new and old ways to create a drive mapping on the local host (that points to a remotely shared folder). The net.exe command, which has been around since the days of Microsoft LAN Manager, enables you to create and view drive mappings. The SMB cmdlets perform similar functions, as you can see here:

In step 4, you created and viewed an SMB share on SRV1, using both net.exe and the SMB cmdlets. This step looks like this:

DNS is all too often the focus of network troubleshooting activity. The Windows DNS client holds a cache of previously resolved network names and their IP addresses. This avoids Windows systems from having to perform DNS lookups every time a network host name is used. In step 5, you looked at the old and new ways to view the local DNS cache, which looks like this:

One often-used network troubleshooting technique involves clearing the DNS client cache. You can use ipconfig.exe or the Clear-DNSClientCache cmdlet, as shown in step 6. Neither the ipconfig.execommand or the Clear-DNSClientCache cmdlet produce any output.

Another troubleshooting technique involves asking the DNS server to resolve a DNS name. Traditionally, you would have used nslookup.exe. This is replaced with the Resolve-DNSName cmdlet. The two methods that you used in step 7 look like this:

There’s more…

In step 1, you looked at two ways of discovering a host’s IP configuration. Get-NetIPconfiguration, by default, returns the host’s DNS server IP address, whereas ipconfig.exe doesn’t. On the other hand, ipconfig.exe is considerably quicker.

Ping is meant to stand for Packet InterNetwork Groper and has been an important tool to determine whether a remote system is online. ping.exe uses ICMP echo request/reply, but many firewalls block ICMP (it has been an attack vector in the past). The Test-NetConnection cmdlet has the significant benefit that it can test whether the remote host has a particular port open. On the other hand, the host might block ICMP, if the host is to provide a service, for example, SMB shares, then the relevant port has to be open. Thus, Test-NetConnection is a lot more useful for network troubleshooting.

In step 2, you pinged a server. In addition to ping.exe, there are numerous third-party tools that can help you determine whether a server is online. The TCPing application, for example, pings a server on a specific port using TCP/IP by opening and closing a connection on the specified port. You can download this free utility from https://www.elifulkerson.com/projects/tcping.php.

If you found this article interesting, you can explore Windows Server 2019 Automation with PowerShell Cookbook to automate Windows server tasks with the powerful features of the PowerShell Language. Windows Server 2019 Automation with PowerShell Cookbook helps the reader learn how to use PowerShell and manage core roles, features, and services of Windows Server 2019.

Windows devices touch issues

In this article i will show you how we can solve the touch issue in windows devices. Now a days we have lot’s of devices are available in the market. So when we are creating a responsive site we have to first fix the device requirement specification from client because we must sure it work properly, user friendly in every device mobile,tablet and desktop and¬†every platform like android,iOS and windows .

Every devices have different specification about touch and it behaves differently. In windows we mostly use IE who handle the touch events differently but in webkit it supports a touch interface that is separate from mouse handling and IE groups the touch,mouse and stylus into a single interface(pointer) it also has been submitted in W3C specification pointer events.

In windows devices IE pointer events model have custom gesture to indicate the area of the page by default gesture handling(pan). we can turn off default gesture handling by using this property -ms-touch-action for example.

However, IE10 on Windows Phone 8 also supports the pan-x and pan-y value of -ms-touch-action property which specify that the browser should handle horizontal or vertical gestures to solve the touch issues in windows, and custom JavaScript handlers should handle everything else.

Note  Microsoft vendor prefixed version of this event (-ms-touch-action) is no longer supported in IE11 and may be removed in a future release. Instead, use the non-prefixed name touch-action, which is better for standards compliance and future compatibility.

Syntax

When a we¬†touches an element, that element’s touch-action property determines the default touch behaviors permitted for that contact, like panning or zooming.

Property values

One of the following values, a combination of the gesture values.

auto
Initial value. Indicates the Windows Store app using JavaScript will determine the permitted touch behaviors for the element.
none
The element permits no default touch behaviors.
pan-x
The element permits touch-driven panning on the horizontal axis. The touch pan is performed on the nearest ancestor with horizontally scrollable content.
pan-y
The element permits touch-driven panning on the vertical axis. The touch pan is performed on the nearest ancestor with vertically scrollable content.
pinch-zoom
The element permits pinch-zooming. The pinch-zoom is performed on the nearest ancestor with zoomable content.
manipulation
The element permits touch-driven panning and pinch-zooming. This is the shorthand equivalent of “pan-x pan-y pinch-zoom”.
double-tap-zoom
The element permits double-tap-zooming. The double-tap-zoom is performed on the full page. Double-tap-zoom is not available in Windows Store apps using JavaScript.
cross-slide-x
The element permits cross-sliding along the horizontal axis.
cross-slide-y
The element permits cross-sliding along the vertical axis.

For more information about web development for windows click here