The Windows Firewall and Business Applications — Register Inbound Rules From the Installer

“It works on the development machine, but once it is installed on the customer’s PC another machine cannot connect to it.” There are situations where a report like this makes you suspect the Windows Firewall. But traffic failing and the firewall blocking it are not the same thing. Sometimes the app is not listening at all; sometimes the destination or the port is wrong; sometimes the allow rule does not match the conditions of the network.

On a development machine, allow rules created in the past are often still there. Verifying behavior in that state does not reproduce how a fresh installation site behaves. Rather than assuming that someone will approve the first-launch warning, the product’s rollout procedure has to cover which traffic is allowed, by whom, and at which stage. Microsoft likewise recommends placing the required rules before the app’s first launch.¹

This article takes a business app that accepts TCP connections from another machine as its main example, and works through rule design, building registration into the installer, and the order in which to check things when traffic fails at a customer site. It assumes Windows 11 and Windows Server operations, and the technical explanations are based on Microsoft’s public documentation as confirmed on September 8, 2026. The product names, paths, ports, and IP ranges in the commands are examples. Replace them to match your own environment.

1. The Conclusion First

There are three points to get straight up front.

• Whether an inbound rule is needed is decided by the direction of the traffic, not by the app’s name. Distinguish between only initiating connections and listening for new traffic from another machine.²
• Place the required rules before first launch. On machines where local management is permitted, the installer is an option; on centrally managed machines, distribution through Group Policy, Intune, or a similar mechanism is.¹
• When something breaks, check in the order listening state, TCP connection, profile, rules, log. What matters is not concluding that traffic is allowed merely because a rule exists, nor that packets never arrived merely because there is no log entry.³⁴⁵⁶

The conclusion of this article, “register it from the installer”, does not mean overriding the organization’s managed policy. It means putting the settings that the traffic requires in place during a rollout step with clear ownership, rather than in a user’s first interaction.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (35 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Getting the Default Behavior Right — Inbound Blocked by Default, Outbound Allowed by Default

The Windows Firewall is a host-based firewall that controls the traffic of the machine it runs on. By default it blocks inbound traffic that is neither a response to a request nor a match for an allow rule, and it allows outbound traffic unless something such as a block rule applies. These are Windows defaults, and they are no guarantee that the customer’s administrator has not changed them.²

For example, if an order-entry client connects to TCP 50051 on the order-entry server, the server is the side that accepts the new connection. The client does not open an inbound port with the same number in order to receive responses on that connection.²

Remote named pipes run over SMB. Common direct-hosted SMB uses TCP 445, so an allow rule for your own app’s exe does not necessarily solve the problem. Distinguish local named pipes from use across the network. SMB authentication and access rights are needed separately as well.⁷⁸

The diagram below, starting from the inbound-block default, is a way to locate the parts that accept connections from another machine. “Inbound rule required” means that a setting allowing inbound traffic is needed; where existing managed rules already cover it, the app does not need to add a duplicate rule. Traffic that stays within the same PC, and UDP traffic, are treated separately from this TCP-connection diagram.

flowchart TB
    APP["Inventory your own app's traffic"] --> Q{"Does it open a port and<br/>listen for connections"}
    Q -- "Does not listen<br/>(only connects as a client)" --> C1["Inbound rule generally not needed<br/>return traffic passes as a response"]
    Q -- "Listens<br/>(server type or callback receiver)" --> S1["Inbound rule required<br/>-> register from the installer (Section 5)"]
    C1 -.-> EX["Exception - where outbound is blocked by default<br/>in a high-security environment, request an outbound rule"]

In environments where the outbound default has been changed to block, or where a rule explicitly forbids the app’s outbound traffic, the connecting side needs an allow rule too. You cannot flatly say “it is a client, so the firewall is irrelevant”.¹ If you want to review the communication mechanism itself, see how to choose an inter-process communication method as well.

2.1. Profiles and the “Network Location”

Every rule carries a condition for which network profiles it is enabled in. The typical way each one applies is as follows.²

You can check the currently connected network with the following command. On machines with several adapters or a VPN, match not only the name but also the interface used for the traffic.²

Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

A rule limited to Domain and Private does not apply if the traffic in question belongs to the Public profile. What matters, though, is not switching the network to Private or widening the rule to every profile just to make traffic pass. Decide with the administrator how far the customer’s network is trusted and which profiles the app is approved for.

2.2. Rule Precedence

With ordinary allow and block rules, an explicit allow takes precedence over the default inbound block, but an explicit block rule that matches the same traffic takes precedence over a conflicting allow rule. This is not a mechanism where whatever was added last wins.¹

So when “we added an allow rule and nothing changed”, look at whether the allow conditions match and also at block rules that apply to the same app or port. Merely having a rule that stops unrelated traffic does not stop all traffic on that machine. Special bypass rules that use IPsec authentication are a different design from the ordinary allow rules covered here.

3. What the “Security Alert” Dialog Really Is — Why You Must Not Rely on It

When an app with no matching rule starts listening, a notification saying “Windows Defender Firewall has blocked some features of this app” appears, depending on the configuration and the runtime conditions. It does not appear on managed machines where notifications have been turned off, so the absence of a warning is no evidence that the traffic was allowed.¹

Microsoft describes the behavior when the notification is shown as follows.¹

Once a rule created this way is left in place, restarting the app does not bring the same prompt back. If a block rule was created in particular, adding an allow rule alone may not resolve it. After checking where each rule came from and whether it is needed, the administrator cleans them up within a limited scope. The app must never delete a block rule that the organization distributed deliberately.

The next diagram shows how a rule gets created from the notification. The conditions under which the notification actually appears, and the wording on screen, vary with the OS and the management settings.

flowchart TB
    L["An app starts listening on a port"] --> Q1{"Is there a rule that<br/>matches that app"}
    Q1 -- "Yes" --> R1["The rule applies<br/>(no dialog appears)"]
    Q1 -- "No" --> Q2{"Are inbound notifications<br/>enabled"}
    Q2 -- "Disabled" --> R2["Blocked silently<br/>(no rule is created)"]
    Q2 -- "Enabled" --> DLG["Windows Security Alert dialog"]
    DLG -- "Administrator chooses Allow access" --> OK["An allow rule is created"]
    DLG -- "Administrator chooses Cancel" --> NG1["A block rule is created"]
    DLG -- "User without administrator rights<br/>(any choice)" --> NG2["A block rule is created"]
    NG1 --> NEVER["The dialog never appears again<br/>until the rule is deleted"]
    NG2 --> NEVER

Even if someone approves it once at rollout time, the conditions remain: another feature starts listening, the network profile changes, an update changes the exe’s path. Inventorying the required traffic first and preparing the rules before first launch makes for a more repeatable rollout.¹

For machines used by non-administrators, Microsoft recommends placing rules in advance and disabling inbound notifications. Notifications can be controlled with Set-NetFirewallProfile -NotifyOnListen False or through Group Policy, but that is a decision for whoever manages the machine-wide notification policy. It is not a reason for a business app’s installer to change, without permission, a notification setting that affects other apps too. Turning notifications off does not allow the traffic you need.¹⁹

4. Designing Inbound Rules — By Program, by Port, by Service

Start by writing out the communication spec split into inbound/outbound, TCP/UDP, listening port, executing entity, remote source, and the network in use. Then combine those into the rule’s conditions.¹⁰

What you pass to -Program is the exe that actually performs the communication, not a shortcut or a launcher. If a separate service or host process is the one listening, the design has to match that executing entity. Even when dynamic ports are in use, do not immediately open every port unconditionally; consider how far you can narrow by program, service, remote source, and so on.¹⁰³

Beyond that, limit the networks in use with -Profile and the remote source with -RemoteAddress. For example, if the order-entry clients are known to sit in 172.16.10.0/24, specify that range. LocalSubnet is a setting you can use on small networks and the like, but it does not mean that “every office in the company” or “the far side of the VPN” is automatically included. Check the actual route and the source address as the receiving side sees it.¹¹⁰

A feature that only uses TCP does not need UDP allowed just in case. And if an internal-only feature is to be enabled on Public as well, be ready to explain the need and the restriction on remote sources separately. The starting point of rule design is to let through only the traffic you need, for the program you need, from the peers you need.

5. Registering Rules From the Installer in Practice — netsh and New-NetFirewallRule

5.1. Prerequisite: Administrator Rights Are Required

Registering, changing, or deleting machine-wide firewall rules runs with elevated administrator rights. Even a user in the Administrators group does not necessarily get by without UAC elevation.¹¹

If you put the registration step in the installer’s elevated phase, the app itself does not have to run as an administrator all the time. Conversely, a per-user installer that completes entirely as a standard user has no permission to change machine-wide rules. In that case, make a separate administrator-run setup, or rule distribution from the organization, a rollout requirement. Keep the situations that require administrator privileges separate from the privileges the app needs for everyday execution.

The following assumes your own exe listens on a fixed port and that the machine permits the installer to manage local rules. It includes nothing that lifts restrictions imposed by managed policy.

5.2. Registering With netsh advfirewall

With netsh you can specify the program, the TCP port, the profiles, and the remote source together as follows. This is an example of a first registration on a machine that does not yet have the same rule. It assumes execution as a batch file from a Command Prompt started as an administrator.¹¹

@echo off
netsh advfirewall firewall add rule ^
  name="MyCompany OrderServer TCP 50051 In" ^
  dir=in action=allow enable=yes ^
  program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" ^
  protocol=TCP localport=50051 ^
  profile=domain,private remoteip=172.16.10.0/24
if errorlevel 1 exit /b 1

Repeating the same add rule does not update anything, and it can leave you with more and more rules of the same name. Deleting the rule and recreating it has its own problem: if registration fails after the deletion, the rule is gone. For products that repeat repairs and updates, the recommendation is a design that fixes an identifier and updates the existing rule, as in the next section.

The removal command is separate. Run the deletion below only at uninstall time; do not append it to the end of the registration batch above. It targets rules matching the name, so use a name that does not collide with other products.¹¹

netsh advfirewall firewall delete rule name="MyCompany OrderServer TCP 50051 In"

Record exit codes and error output in the installer’s log, and distinguish “registration failed”, “already deleted”, and “no permission”. It also matters not to tell the user that the communication setup is complete when registration has in fact failed.

5.3. Registering With PowerShell (New-NetFirewallRule)

The NetSecurity module in PowerShell lets you separate -Name, which identifies the rule, from -DisplayName, which is shown on screen. For a script’s identifier, use a fixed -Name that is unaffected by the display language or by wording changes.¹⁰

Next is an example for install, repair, and update that does not multiply rules when the same processing runs again. It uses Set-NetFirewallRule if the rule already exists and New-NetFirewallRule if it does not. The parameter for updating the display name is -NewDisplayName.¹²

# For install, repair, and update. Run as an administrator.
$ErrorActionPreference = "Stop"
$ruleName = "MyCompany-OrderServer-In"
$displayName = "MyCompany OrderServer (TCP 50051 inbound)"
$program = "C:\Program Files\MyCompany\OrderServer\OrderServer.exe"

if (-not (Test-Path -LiteralPath $program -PathType Leaf)) {
    throw "Executable not found: $program"
}

# Settings for the local rule this product owns.
# Replace the remote source and the profiles with values agreed with the site administrator.
$settings = @{
    PolicyStore   = "PersistentStore"
    Direction     = "Inbound"
    Action        = "Allow"
    Enabled       = "True"
    Program       = $program
    Protocol      = "TCP"
    LocalPort     = 50051
    Profile       = @("Domain", "Private")
    RemoteAddress = "172.16.10.0/24"
}

# Distinguish "the rule does not exist" from a failure of the query itself.
$existing = @(Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq $ruleName })

if ($existing.Count -eq 0) {
    New-NetFirewallRule -Name $ruleName -DisplayName $displayName @settings |
        Out-Null
} else {
    Set-NetFirewallRule -Name $ruleName -NewDisplayName $displayName @settings
}

What this example changes is only the rule in the PersistentStore whose name your company manages. Do not use the same identifier for another purpose. And in a product that later added conditions such as a source port or a service, design the migration of those conditions explicitly as well. Set-NetFirewallRule does not reset every condition you did not specify back to its initial state.¹²

Deletion goes into the following uninstall-only processing. It deletes nothing if the target rule is absent, but it does not hide a failure of the query or of the deletion itself.⁵⁹

# For uninstall. Do not run it immediately after the registration processing.
$ErrorActionPreference = "Stop"
Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq "MyCompany-OrderServer-In" } |
    Remove-NetFirewallRule -ErrorAction Stop

These are examples of the registration processing, not an implementation of the installer’s overall transaction. When you build them into a product, confirm that a failed setting change is reported back to the installer, that a failed update can roll back to the old version and the old settings, and that uninstall deletes only your own rules.

5.4. When an Update Changes the exe Path

A program-based rule uses the registered path as its condition. For example, even if a rule exists for the exe in the v1.0 folder, once the exe in the v1.1 folder is the one listening after an update, that old rule no longer matches the new exe.¹¹⁰

The next diagram covers the case where you depended only on that old-path rule. It does not uniformly represent cases where another effective allow rule exists, or runtime conditions in which no notification appears.

flowchart TB
    V1["v1.0 is installed<br/>the rule points at the exe in the v1.0 folder"] --> UP["An update places it in the v1.1 folder<br/>the path of the exe that runs changes"]
    UP --> MISS["The old-path rule loses sight of its target<br/>(the rule remains but has no effect)"]
    MISS --> Q{"Are inbound notifications<br/>enabled"}
    Q -- "Enabled" --> DLG["The dialog is shown again<br/>a block rule if an ordinary user responds"]
    Q -- "Disabled" --> SILENT["No dialog either<br/>blocked silently"]
    MISS -.->|"Remedy"| FIX["Keep the path fixed across updates<br/>or delete and re-register the old rule during the update"]

The remedy is either to keep the exe’s full path fixed across updates, or to change the rule to the new path during the update step. With the approach in Section 5.3, you can update the rule with the same -Name to the new path. If you choose to delete the old rule and register it again, implement the restore-on-failure path as well, so that you never leave only an old, broad allow rule behind.

For MSI there are mechanisms that handle rules declaratively, such as the WiX firewall extension. Before launching commands from a custom action of your own, check which conditions the tool you use supports and how it handles updates and removal.¹³ The thinking behind each distribution method is covered in Choosing a Windows App Distribution Method, and antivirus detection in Handling Microsoft Defender False Positives.

6. Troubleshooting — A Triage Flow for “It Cannot Communicate”

When a report comes in, first gather the source and destination, the name or IP address used, TCP/UDP and the port, the time of failure, and the app’s error. The example below is an order-entry server that uses TCP. Do not mix the items you check on the server with the items you test from the actual client.

TcpTestSucceeded=True in the diagram means that the TCP connection to the destination you tested succeeded. It does not guarantee that the app’s authentication, TLS, and data exchange succeeded, nor that outbound traffic from the business app, which is a different executable, is allowed.⁴

flowchart TB
    S["Cannot communicate from the client"] --> N["On the server - netstat -ano"]
    N -- "Not listening" --> APP["A problem upstream of the firewall<br/>investigate the app or service side"]
    N -- "It is LISTENING" --> T["On the client - Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["Reachability is fine<br/>investigate the app layer (authentication, protocol)"]
    T -- "False" --> P["On the server - Get-NetConnectionProfile<br/>check the profile in effect"]
    P -- "Does not match the rule's scope" --> FIXP["Revisit the rule's profile setting"]
    P -- "It matches" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>check for allow rules and for stray block rules"]
    R --> LOGCHK["Measure drops (DROP) in pfirewall.log"]

1. For the listening state, look at the address and the process, not only the port. Even with LISTENING, if it is bound only to 127.0.0.1 or ::1 it is not a listener another machine can connect to as-is. Check whether it listens on the LAN address in question, and whether another process is using the same port. Match the PID from netstat -ano against Task Manager or a similar tool, and with the necessary privileges netstat -abno also reveals the executable. Check IPv4 and IPv6 separately.³

2. Run the TCP connection test from the actual client. In the example below, check RemoteAddress, SourceAddress, InterfaceAlias, and TcpTestSucceeded.⁴

# Run on the client. Replace the name and the port to match your environment.
Test-NetConnection -ComputerName sv01 -Port 50051 -InformationLevel Detailed

A False does not establish the Windows Firewall as the cause. Name resolution, the destination, the route, a VPN, network equipment, and traffic controls from another product are all candidates as well. Conversely, if it is True, first confirm that the destination is the server you intended, and then look at the business app’s destination settings, its authentication, and its protocol. Testing with an IP address is usable for comparing TCP reachability, but it does not necessarily behave the same as name-based authentication or certificate validation. The -Port parameter of this cmdlet is a TCP test and is not used to decide whether UDP succeeds or fails.⁴

3. The profile and 4. the rules are checked against the settings that actually apply. Get-NetFirewallRule looks at the local persistent store by default. To see the current policy, including what comes from Group Policy and the like, specify -PolicyStore ActiveStore. Check not only that the rule exists but the profile-side settings as well.⁵¹⁴

# Run on the server as an administrator.
Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
        AllowInboundRules, AllowLocalFirewallRules

$rules = @(Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Where-Object { $_.Enabled -eq "True" -and $_.Direction -eq "Inbound" })

$rules | Select-Object Name, DisplayName, Action, Profile,
    PolicyStoreSourceType, PolicyStoreSource

In a configuration where AllowInboundRules is disabled, adding an allow rule is not enough to permit inbound traffic. Whether local rules apply at all is judged together with the managed policy in Section 7. For unconfigured values such as NotConfigured, do not conclude allowed or not allowed from that string alone; confirm the effective settings with the administrator.¹⁵

The program, the port, and the address live on the filter objects associated with the rule. The example below displays each of the conditions on your own rule. For $rules, use what the command above retrieved.^5161718

$targetRules = @($rules | Where-Object { $_.Name -eq "MyCompany-OrderServer-In" })
$targetRules | Get-NetFirewallApplicationFilter | Select-Object Program
$targetRules | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort, RemotePort
$targetRules | Get-NetFirewallAddressFilter | Select-Object LocalAddress, RemoteAddress

# Also investigate block rules whose names differ from your own rule.
$rules | Where-Object { $_.Action -eq "Block" } |
    Select-Object Name, DisplayName, Profile, PolicyStoreSourceType, PolicyStoreSource

For block rules too, check the filters on the candidate rules the same way. If a service is specified, look at that condition as well, with Get-NetFirewallServiceFilter and the like. An exact-match search such as LocalPort -eq 50051 on its own misses rules that specify Any or a port range. Do not conclude “it did not show up in the search, so there is no conflicting rule”.¹⁷⁵

5. For the log, enable recording and then reproduce the problem. By default the firewall log records neither allowed nor dropped traffic. The default location is %windir%\system32\logfiles\firewall\pfirewall.log, and the default maximum size is 4,096 KB. Start by checking the settings for the profile in question and the actual location.⁶

# On the server. Read only for now, and change no settings.
Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, LogBlocked, LogAllowed, LogFileName, LogMaxSizeKilobytes

If drop logging is disabled, obtain the administrator’s approval and enable it for the target profile only, with something like Set-NetFirewallProfile -Profile Private -LogBlocked True. Private here is an example. Record the settings as they were, and restore the original values after the investigation. If the settings are centrally managed, have the management side change them; there is no need to start by recording allowed traffic in bulk or by changing every profile.⁹⁶

If there is a DROP matching the time of the reproduction, the source IP, the destination IP, the protocol, and the port, you can confirm that the traffic was dropped. However, the absence of such a line alone does not establish that “the packet never arrived”. First confirm that the logging settings are applied, that you are not looking at a different location, that the file is being updated, and that there is no problem with write permissions. Combine this with a packet capture or similar if needed. When the log file is never created, follow Microsoft’s procedure for checking the folder and the mpssvc permissions as well.⁶

To dig further, the Windows Filtering Platform audit events 5152 and 5157 are candidates. Per-packet auditing generates a huge number of events, so Microsoft points to the per-connection event 5157 for monitoring blocked connections. Confirm the audit policy and the volume of records with the administrator, and narrow the scope and the period to what is needed.¹⁹

Do not make disabling the firewall your first diagnostic step or your permanent fix. Stopping the MpsSvc service in particular is unsupported by Microsoft. Even when an administrator runs a comparison test in an isolated lab environment, leave the service running, limit the change to the profile in question, and make restoring the original settings mandatory. What production needs is a setting corrected to match the cause, not defenses removed wholesale.²

7. Notes Under Central Management — Environments Where Local Rules Have No Effect, and How to File a Request

In environments where the firewall is centrally managed through Group Policy or Intune, local rule merging can be disabled per profile. In that case, even if the installer can create a rule in the local persistent store, it is not applied as a setting that allows traffic. A successful registration step and the change reaching the effective policy are two different things.¹

“Rules created locally” in the diagram means ordinary local rules such as the ones created in the PersistentStore in Section 5. They are treated differently from rules configured through local Group Policy. This is not a matter of writing to a different store to get around the restriction; it is a distinction that exists so that you and the customer’s administrator agree on a single source of distribution.¹

flowchart TB
    GPOR["Rules distributed by GPO or Intune"] --> EFF["The set of rules actually in effect<br/>(ActiveStore)"]
    LOCAL["Rules created locally<br/>(including installer registration)"] --> Q{"Local rule merging<br/>(AllowLocalPolicyMerge)"}
    Q -- "Enabled (default)" --> EFF
    Q -- "Disabled" --> DROP["The rule exists but is not applied<br/>-> switch to central distribution via GPO or CSP"]

In such an environment, rather than recreating local rules over and over, ask the IT department to distribute the rule. The installer should distinguish whether it manages the rule itself or assumes distribution from the management side, and be designed so that it does not change the management policy on its own.

A request needs at least the following information. Please open TCP 50051 on its own does not settle which machine, whose traffic, or how far the allow extends.

Do not finish rollout testing with connections from the development machine or the server itself; run it in the actual location of use and with the actual privileges. If there are several routes, such as one over a VPN, check each route. If authentication fails after the TCP connection goes through, move on to an investigation separate from the firewall. For the related topics of authentication and traffic protection, see SMB Signing and LDAP Channel Binding as well.

8. Summary

Dealing with the Windows Firewall does not end with “approve it at the warning” or “open one port”. The starting point is to inventory the app’s traffic directions, design the program, the port, the remote source, and the profile together, and place the required settings before first launch.¹¹⁰

If local management is permitted, make registering, updating, and deleting the rule part of the installer’s responsibility. If the machines are managed through Group Policy or Intune, hand the same communication spec to the administrator and have it distributed. Make the condition for a completed rollout not that a rule could be created, but that the intended peers can communicate with the actual app and that no unnecessary range is allowed.

When traffic fails, check in order the listening address and the executing entity, the TCP connection, the profile, the effective policy, and the drop log. Rather than leaping to “it does not connect, so it is the firewall” or “there is no log, so it never arrived”, separating what each result told you from what you still do not know makes the next place to look clear.

Related Articles

• Choosing Windows Inter-Process Communication ── A Decision Table for Named Pipes / TCP / gRPC / Shared Memory / COM
• Choosing a Windows App Distribution Method - MSI/MSIX/ClickOnce/xcopy/Custom Updater
• When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design
• When Your In-House Windows App Gets Flagged as a Virus — Handling Microsoft Defender False Positives and Living With the Performance Impact
• SMB Signing and LDAP Channel Binding — Closing the “Other Half” of Your NTLM Defences in Practice
• How to Build and Operate Windows Services ── From Choosing Between Task Scheduler and Services to Turning a BackgroundService into a Windows Service

Related Consulting Areas

In addition to developing Windows business applications, KomuraSoft LLC handles installer design that includes firewall rules, root-cause investigation of connectivity failures at customer sites, and technical consulting toward rollouts under central management. When you get in touch, having the source and destination, the communication method, the reproduction steps, and any errors or logs lets us make the scope of the investigation concrete.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Technical Consulting & Design Review
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Does an app that only connects to a server as a client also need a firewall rule?

In an environment where outbound traffic is allowed by default, an app that only initiates connections and receives the responses to them normally does not need an inbound rule of its own. That changes if an organizational policy restricts outbound traffic or an explicit block rule exists. Also, even an app called a client needs inbound traffic allowed for any part of it that listens for callbacks or notifications from another machine. Decide from the actual direction of the traffic, not from what the app is called.

Can't I just press "Allow access" on the "Windows Security Alert" dialog and be done with it?

It is safer not to let your production rollout procedure depend on that single action. Microsoft documents that a block rule is created when the administrator who sees the notification cancels it, or when a user who is not an administrator responds to it. Adding an allow rule afterward does not get the traffic through while a conflicting block rule exists. Place the required rules before first launch, either from the installer or through the organization's administrator.

Should an inbound rule be built around the port or around the program?

For an in-house app that listens on a fixed port, the baseline is to combine the program's full path with the protocol and the local port, and to narrow the remote IP and the profile to the range actually needed. Adjustments are needed for the configuration at hand, such as dynamic ports or running as a service. With a program-based rule, make the update process account for changes to the executable's path, and avoid casually creating a broad port-only allow rule.

The rule our installer registered does not seem to take effect on the customer's PC. Why?

A successful rule registration on its own does not tell you that the traffic is allowed. Check the listening address, the executable's path, the profile, the remote IP, and any conflicting block rule. On top of that, if local rule merging is disabled through Group Policy or Intune, the rule the installer created is not applied. In that case, do not work around the managed policy; switch to having the IT department distribute the rule.

Is it acceptable to disable the firewall temporarily in order to triage a connectivity problem?

Investigate first through the listening state, the effective policy, and the drop log. Do not make disabling the whole firewall a routine response, and in particular avoid stopping the MpsSvc service, which Microsoft does not support. Even when an administrator does need to disable it temporarily in an isolated test environment, leave the service running, limit the change to the profile in question, record the settings as they were, and restore them immediately.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.