Fix Unidentified Network Access: Local Only Internet Issue in Windows Vista

Fixing the local only internet access issue in Windows Vista | The Bit Guru:

'via Blog this'


Sharing from a very helpful article that allowed me to fix an issue in Windows Vista in which when connecting to a WiFi network, the wireless connection is labeled as Unidentified and Access: is Local Only, causing users to not be able to connect to the internet.  Issue is due to a bug in Windows Vista and thought to share it.  I browsed the web in search of a fix and this did the trick.

The cause (From Microsoft):

By default, the BROADCAST flag in DHCP discovery packets is enabled in Windows Vista (DhcpConnEnableBcastFlagToggle = 1). Therefore, Windows Vista gets an IP address by using the BROADCAST flag in DHCP discovery packets. If a router or DHCP server can’t process the DHCP discovery packets, Windows Vista will fail to get an IP address. The fix disables the BROADCAST flag by setting DhcpConnEnableBcastFlagToggle to 0.
By default, this problem does not exist in Windows XP Service Pack 2, Windows XP Service Pack 3 or Windows 7 because the BROADCAST flag is disabled (DhcpConnEnableBcastFlagToggle = 0.

As suggested by Farhan Ahmad, I first tried the automatic fix by Microsoft; this fixed the issue initially.  However, a couple of days later Windows Update installed new updates on the computer and the issue happened again.  System Restore did not fix it. Neither did running the Fix IT application from Microsoft again.  Again I did as the original post suggested and tried uninstalling the wireless card drivers, restarting the computer and then reinstalling the wireless card drivers.  This worked for me.  Much thanks.

The IT Department is Useless: 10 Reasons Why that is Not True

What has your IT Department done for you lately? The IT Department is useless, or perhaps it's just misunderstood. In many industries, Healthcare especially, the IT Department is useless.

At least that is the way it is perceived. The IT department is often times viewed as an obscure group of high paid nerds that sit around surfing the web for most part of the day. IT department staff are sometimes thought of as know-it-all that look down on the less computer savvy, hard-working staff. 

The IT Department is useless because they are never around when you really need them and bug staff with an endless list of protocols to follow. They are also the snitches, the all-seeing eye, making sure you cannot get around to post on your Facebook or respond to personal email. Heck, they are probably watching you right now!  This, of course, is a misconception and while there are some bad apples, the assumption that the IT department is useless is wrong. The IT Department, if anything, is misunderstood.

• The IT Department is not useless because it is responsible for keeping your computers running. While your own computer may be down for some time, usually, you will have access to some other workstation temporarily.
• The IT Department is not useless because it is responsible of keeping you connected to applications and services and to the web. While there may be some issues, for the most part, an organization cannot function without these vital business tools.
• The IT Department is not useless but often times understaffed. If your workstation has been down for days, chances are that it is not the only one; but, there may be only one computer technician per 100 computers...probably more.
• The IT Department is not useless because IT staff usually serve dual or triple roles in the organization. That is, the computer technician may also be doing some networking and helping out with administrative tasks such as developing IP lists, Software and Hardware Inventory Lists aside from their core responsibilities.
• The IT Department is not useless. IT staff is very unlikely to be monitoring your internet usage specifically and certainly are not out to get you.  Unless of course, your web activity is causing problems on the network or poses a security risk.
• The IT Department is not useless because keeping the network safe and stable is of the highest priority. As such, they will look at whatever is causing problems in the network or the workstations that have been recently infected with viruses, malware, etc. If that happens to be because a certain staff member is listening to Pandora or downloading wallpapers then company policy dictates the incident to be reported, thus, making IT staff look like the company snitch. The truth is, our job depends on how well we can do our functions and we are often put in situations in which we either do the right thing and report a vulnerability or turn a blind eye to keep others from getting in trouble.
• The IT Department is not useless. IT Department staff are often seen sitting around but that is just the nature of the job they perform. It involves a lot of thinking; that is always better done sitting down, sipping a cup of coffee and staring blankly at a computer screen. Rest assured, the guy is not under hypnosis, but is working on resolving your co-worker's computer problem.
• The IT Department is not useless. The To-Do list for IT Department staff is endless. There are always assessments to be made, holes to be patched, computers to be replaced, software and hardware to be installed, lists to be made, documentation, reporting, maintenance, etc. They won't be able to get them all at once so setting up priorities will enable the business to carry on as usual. Ask yourself this question: What is most important to the boss and to the organization as a whole? Sadly, fixing the printer closest to you is probably going to land somewhere down the bottom of the list depending on what else is at stake.
• The IT Department is not useless and is not all-knowing. Technologies are constantly evolving. Old ones are scrapped and new ones are under development. As such, IT department staff has to perform a great deal of research to stay on top of things.
• The IT Department is not useless and Information Technology, in some way, is like the healthcare industry. A nurse will not operate on a patient because she is not trained or qualified to do so. A general surgeon will know little about brain trauma and the podiatrist will not know how to do bypass surgery. Likewise, there are many different branches of Information Technology yet the computer technician working on a printer is sometimes expected to do something about EHR's poor performance or the fact that printers are not working in a Citrix Published Desktop.

Those of us who work in IT usually love what we do. A lot of us like helping people out or at the very least, we like the challenge of solving a problem. We are on your side. What's the IT Department like in your organization?

Why I Don't Do Hosted Fax Service - Healthcare IT

Hosted fax service is a shady line when it comes to security and HIPAA. Undoubtedly there are great benefits to a hosted fax service such as:

• The ability to share the same account amongst many users makes the service low cost.

• The benefit of sending faxes via the email client means fewer hassles for users.

• A hosted fax service will usually offer Print-to-Fax functionality allowing you to fax out anything you can print.

• You get no busy signals when receiving faxes.

• The use of a fax queue that holds fax jobs until the resources are available to be sent is seamless to the user and allows for faxes to be sent out one after the other without having to wait.

• Automatic fax transmission notifications are sent out by default.

• A hosted fax service is more cost effective than traditional faxing because it saves on equipment, equipment maintenance, ink, paper and traditional analog lines.

• Faxes can usually be resent from the web portal.

• Hosted fax service usually provides limited fax storage.

• The signup process and account management is simple.

• With hosted fax service, you have access from anywhere using an internet connection via the web portal.

As beneficial as hosted fax service is, when it comes to Healthcare Information Technology, we must look at it from a regulatory perspective as Community Health Centers and other healthcare institutions are subject to HIPAA laws and other regulations. Thus, I do not do hosted fax service for the following reasons:

1. In order to be HIPAA compliant, users cannot share the same account for the service as the sharing of passwords is explicitly prohibited for systems containing ePHI. Thus, the number of hosted fax service providers is limited since many do not have safeguards in place to provide logins and a separate workspace for individual users.
2. Sending faxes through the use of email clients, in my opinion, is a vulnerability because email accounts are often setup for use on portable devices that are at greater risk of being lost or stolen. Thus, ePHI stored in the Sent Items is visible to whoever has the device.
3. ePHI can be accessed on a desktop by going to the Sent Items on the email client, and with some hosted fax service providers, it can also be accessed via the Print-to-Fax cache on the workstation.
4. Email clients don't usually ask for a password by default. This circumvents the technical safeguards put in place with the implementation of an EHR.
5. Also, depending on whether you have an in-house email server or hosted, the setup for secured transmissions is more involved and should include SSL.
6. If an email account is ever black listed for spam, that may disrupt the faxing service as well.
7. If the email server goes down, you are unable to fax out unless the hosted fax service provides an alternate method for fax transmissions.
8. The faxes are stored off-site with the hosted fax service provider; the liability of a breach still rests with the covered entity. At the very least, a Business Associate Agreement (BAA) is needed.
9. The ability to access the hosted fax service from anywhere constitutes another risk as users will have access to ePHI even after business hours and from off site with no oversight.
10. The ability to access the web portal from outside the network increases the risk for man-in-the-middle attacks and network sniffers.
11. Most hosted fax service providers do not support a Citrix environment with the exception of a few such as RightFax and GoldFax.  Perhaps the good people at +RightFax Pros can offer a solution.

While hosted fax service may be perfect for most organizations, Community Health Centers and other healthcare institutions should look for an in-house electronic fax solution to be in compliance with HIPAA regulations. I wonder if +HIPAA For MSPs  would like to comment on this post.

How To Install HP t610 Thin Client in 30 Minutes

Do you want to know how to set up a thin client in 30 minutes flat? Learning how to set up a thin client is almost a pre-requisite in many of today's current network environments as more and more organizations move towards virtualization. There are various ways on how to set up a thin client. The following allows me to set up a thin client in 30 minutes.

 First and foremost, there must be a documented process to follow. If you have set up 100+ thin clients before, then the process on how to set up a thin client is probably engraved in your tired brain by now. If you are like me though, you may need a little extra help in remembering the steps on how to setup a thin client. In knowing how to set up a thin client, I cannot stress enough the importance of developing a sound process and documenting it. It is for your benefit and will allow you to achieve your goals quicker, more effectively and with fewer mistakes. What's more, being able to develop a process and document it will set you above others in any field.

Our organization currently uses Wyse, HP t5740e and HP t610 thin clients; we are soon to include the HP t620 model. This post focuses on how to set up a thin client an HP t5740e and HP t610 thin client.  Both have Windows XP Embedded OS. As such, they act very much like mini copies of Windows XP but with much less functionality and features. How to set up a thin client in 30 minutes can be broken down as follows:

1. Un-boxing, connecting and powering up equipment. 8 minutes.
2. Flashing the thin client with a custom thin client image. 12 minutes.
3. Configuring thin client embedded OS and applications. 10 minutes.

The process outlined above on how to set up a thin client has been simplified and is achievable by taking special care of the following:

1. Workspace - the physical location where the thin client will sit must be prepped and ready beforehand. When someone calls in a request for a new thin client in our organization the first thing that I think of is to notify the leader of that department to make sure the area is clean and that there is furniture in place for the thin client to rest on. I later make a quick stop to verify that available electrical outlets and data ports are close by and live. Grommet holes, if necessary must have been made prior, usually by maintenance staff.
2. Checklist - all materials, hardware and tools must be allocated and on-hand for the installation to go smoothly. I have a checklist of the items I need which include the following:
   1. thin client
   2. monitor
   3. power surge protector
   4. tools (I use a Leatherman Wave pocket knife)
   5. cat5 cables (for thin client, VOIP phone, and rack)
   6. cable ties or velcro and/or looming
   7. USB thumb drive with the thin client image to be deployed
   8. thin client configuration procedures

3. Access - schedule yourself to be on site and make sure that you will have unrestricted access to the work area and the communications closet. It would also help to have a knowledgeable contact in the department where the thin client will be located that can answer questions you may have regarding the setup.

While everything on the previous list is important on how to set up a thin client, there are two items that are essential and without them, setting up a thin client in 30 minutes will not be possible.

• the thin client image - the thin client image is composed of the Windows Embedded OS, installed software applications and pre-configured settings. Developing a custom thin client image for your organization is very important because that will save you a great deal of time during setup. A thin client custom image will also prevent mistakes. Every organization should have a list of applications and configurations that are standard to all thin clients. Developing a thin client image is time consuming. It requires planning, and some knowledge of the embedded OS. It requires pre-configuring various OS and application components and must be tested several times before it can be used for companywide deployments. It is well worth the effort as it allows you to deploy thin clients left and right at a whim. There are various ways on how to deploy a thin client image. I currently use two methods.
  • Vendor deployed image - all of our thin clients purchased come with the thin client image already deployed from the vendor. It is a custom thin client image that I have created, tweaked and tested a million times before providing it to the vendor. The vendor charges us a fee for having the image deployed on all thin clients we order. This allows me to be able to set up a thin client in 20 minutes rather than 30 minutes as I no longer have to flash the thin client during setup.
  • USB thumb drive - the software to create a thin client image using a USB thumb drive is available on HP t5740e and HP t610 thin clients in the control panel. Once you have installed all standard software and made necessary changes to the OS you can capture the thin state of the thin client and have it saved to USB.
• thin client configuration procedures - tailored specifically for your virtual and network environment, thin client configuration procedures will save you a great deal of time in setting up a new thin client. Thin client configuration procedures are a corner stone on how to set up a thin client. These procedures are intended to guide staff, making sure that no mistakes are made in the configuration process and nothing is open to interpretation or assumptions. All is documented and must be adhered to. The result is a working thin client that is up to company specs each and every time. Thin client configuration procedures should be based on the thin client image being deployed. Every organization deploying thin clients should create thin client configuration procedures for technical staff to follow. Procedures should include step-by-step instructions on how to configure all pertinent settings.

  *Special Note on how to set up a thin client: The process of configuring a thin client is two tier. As much as is possible and reasonable should be pre-configured with the Windows Embedded OS image. This will reduce the number of changes needed to be made individually on each thin client.

The following is the Table of Contents from the thin client configuration procedures I have created for our organization to give you an idea of what should be included. It is best to outline it in chronological order and to be as thorough as possible. Include screenshots with your instructions to make it more understandable.

How to Set Up a Thin Client - Thin Client Configuration Procedures *Applies to thin clients using custom flash version: 5.1.989

Contents

Section I: LOG IN TO LOCAL ADMINISTRATOR ACCOUNT
Section II: CHANGE TIME/DATE
Section III: CONFIGURE DNS SETTINGS
Section IV: CHANGE SCREEN RESOLUTION
Section V: CHANGE COMPUTER NAME
Section VI: ADD THIN CLIENT TO DOMAIN
Section VII: LOG ON TO DOMAIN as ADMINISTRATOR
Section VIII: CONFIGURE TEAMVIEWER
Section IX: DISABLE INTERNET EXPLORER FOR DOMAIN USERS
Section X: DELETE ClientName REGISTRY KEY
Section XI: CHANGE XENAPP APPLICATION IN PROGRAM NEIGHBORHOOD
Section XII: INSTALLING A PANASONIC KV-S1025C SCANNER
Section XIII: CONFIGURE DOMAIN USER ACCOUNT AUTO-LOGIN
Section XIV: ENABLE WRITE FILTER

In closing, on how to set up a thin client, plan ahead, develop a thin client image specific to your organization to use with all new installations and develop step-by-step procedures to guide you through the configurations. How do you set up a thin client in your organization?

HIPAA Security Rule Section 164.312 Encryption and Decryption

This post is about HIPAA Security Rule Section 164.312 Encryption and Decryption. Encryption is a process used to make data incomprehensible to unauthorized users and readable to authorized users by encoding. In healthcare information technology, encryption is a very important tool in protecting patient data and is addressed in HIPAA Security Rule Section 164.312 Encryption and Decryption under Technical Safeguards.

Understanding HIPAA regulations dealing with the protection of electronic Protected Health Information (ePHI) can be daunting, yet extremely important. If you work in Healthcare IT you may already be familiar with 45 CFR § 164.312 Technical Safeguards (a)(2)(iv) Encryption and Decryption. This is the section dealing with the encryption of ePHI data and or devices that store, transmit, or work with ePHI (i.e. disk drives, USBs, directories, etc.) The rule reads as follows:

"(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information."

Well, that seems very to the point. But just what does Addressable mean as pertains to HIPAA Security Rule Section 164.312 ? Are covered entities required to encrypt or not? It took a bit of research and half a cup of coffee but here is the answer coming from a reliable source.

"Is the use of encryption mandatory in the Security Rule? Answer:No. The final Security Rule made the use of encryption an addressable implementation specification. See 45 CFR § 164.312(a)(2)(iv) and (e)(2)(ii). The encryption implementation specification is addressable, and must therefore be implemented if, after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its risk management of the confidentiality, integrity and availability of e-PHI. If the entity decides that the addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision."

via Is the use of encryption mandatory in the Security Rule?. Thus, in order to comply with HIPAA Security Rule Section 164.312 encryption requirements, a covered entity must conduct a Security Risk Assessment first to determine if encryption is warranted for their organization and to what extent. If they find it inappropriate or unreasonable, the reasoning behind that determination should be documented.

EHR Performance Issues Hard Drive Bottleneck HDD Active Time HDD Response Time Disk Queue Length

This post is about EHR performance issues as a result of a hard drive bottleneck. While this post relates to a server environment, the same principles apply to personal computers running Windows.

EHR performance issues can arise for many different reasons including bad network performance, bad client side performance, faulty configurations, etc. As ruling out all the possible causes of EHR performance issues can prove tedious and timing is critical, I recommend closely monitoring the server hardware often to address possible hardware problems before they occur. I do so daily. In fast-growing health centers this is especially important to avoid overloading the system due to an increase in the number of supported users. When EHR is first deployed, the deployment team will usually conduct a detailed analysis of the organization and usage needs to allocate proper resources to the server hardware. As these systems are tailored based on that early assessment, if the EHR implementation is planned to support between 100 - 250 users, increasing the number of EHR users in two years to 350+ may cause EHR performance issues depending on the scalability that was built in.

In the image below, notice that there is sufficient drive space available on the server.

 But drive space is not the issue in this scenario. When looking for possible EHR performance issues due to a hard drive bottleneck, it is important to know how many physical disks are part of the array. Using Windows Resource Monitor, we can determine that there is an insufficient amount of hard drives to respond to Input/Output (I/O) requests. Notice that for Drive E, Active Time and Response Time are too high.



 EHR Performance Issues – Hard Drive Bottleneck Active Time is the percentage of time that the disk is in use. If Active Time is constantly reaching 100%, this is strong indication that the disk cannot handle the current load. Response Time is the time it takes for the disk to respond to I/O requests. The lower the number is, the better. Anything above 25ms is bad, although this can depend of the size of data being written and retrieved. For additional information regarding Windows Resource monitor click here.

The problem we are seeing in this example is that read/write requests are too many for the two disks that compose the array to service. Thus, if you look at the Disk Queue Length you will notice that there is too high a number in queue causing the drive to be constantly at 100%. This will cause lag in changing tabs, viewing documents, saving changes, closing nurse encounters, etc. The Disk Queue Length should never be more than 2 per physical disk in the array as that is a sign of a hard drive bottleneck. Thus, since Drive E is composed of two disks, the Queue Length for Drive E should not exceed 4; if say, a disk array is composed of four disks, then the Disk Queue Length should not exceed 8. As seen in this example, Drive E Disk Queue Length was constantly at between 8 and 10.

In this scenario, adding two more physical disks to the array will allow for better response time since more disks will be available for servicing requests. This in turn reduces Response Time, Queue Length and Active Time eliminating EHR performance issues caused by a hard drive bottleneck.

Polycom SoundPoint IP 650 Call Coverage Not Working - Netvanta 7100 PBX

You have a Netvanta 7100 PBX phone system and a Polycom Soundpoint IP 650 phone as part of your VOIP infrastructure.  The phone boots up and all is working; the world is a happy place.  Then you attempt to make changes to Call Coverage through the Netvanta 7100 Management Console; say for example that instead of having the phone ring the system default number of times, you want it to ring 9 times before it transfers to the Auto Attendant.  The first thing is to change User settings for that extension in the management console.  After making the changes you realize that, although there were no errors, the changes you made did not have any effect on the number of times the phone rings when the extension is dialed.

Next, one might think of setting the phone to Factory Default by pressing 468* as the phone is booting up, then entering the password; default password for the Polycom SoundPoint IP 650 phone is 456  Upon booting up successfully, the phone still only rings the same amount of times.  What is going on?  The mac-phone.cfg file could be the culprit.  This file is present in CFlash if a user made manual changes to the Polycom SoundPoint IP 650 phone.  If you take a look at mac-phone.cfg in notepad, you may find this to be the cause of management console settings being overridden.  To fix this, you can reset the configuration file on the phone through the phone's LCD menu.  This file does not need to be present in Flash or CFlash for the VOIP phone to operate.

Upgrade Symantec Endpoint Protection 11.x to Symantec Endpoint Protection 12.1.5 How To Video

Netvanta 7100 R11.4 Adtran/Polycom SoundPoint IP Phone Configs Error

Continued from previous post...

As it turns out, the issue with Polycom SoundPoint IP Phone Configs error was due to a new feature in AOS 10.8 and above.  The 7100 can now be configured with multiple SIP application and BootRom for Polycom SoundPoint IP phones.  Since this setting was not available before the upgrade, nothing was configured on my Netvanta 7100.  It was causing my IP Phone Configs files to appear as deprecated and in orange.  When editing IP Phone Configs and selecting a new phone model from the list, the phone became unbootable because the current sip.ld and bootrom.ld version on the phones were not selected under IP Phone Globals - Boot Settings - Polycom Default Firmware.  A great deal of hours and multiple 16oz cups of coffee later I see the light.

Polycom SoundPoint IP Phone Configs Error

Recapping, I recently upgraded the firmware on 3 Adtran Netvanta 7100 PBX phone systems after having networking problems with older system firmware on two units and replacing a third.  Although I checked for the IP phone firmware to be supported by the newer AOS PBX firmware, after the upgrade under the IP Phone Configs tab all are shown in orange and an error states that the phone model is deprecated and I need to select a new phone model.  This is affecting all our Polycom SoundPoint IP 335 phones and Polycom SoundPoint IP 650 phones.  From the selection list provided, Polycom SoundPoint IP 335 is no longer available; instead, I have to pick Adtran/Polycom IP 335.  When selecting the new phone model for this particular phone, the phone then becomes unbootable.   I was able to test and reproduce this in a mock environment.  After trial and error, I finally managed to boot the phone successfully, however, when testing in a live environment, it did not work and the phone I was testing on got stuck in a reboot loop.

Polycom SoundPoint IP 650 - Affected

Polycom SoundPoint IP 335 - Affected

Adtran IP 706/712 - Not Affected

The AOS configuration files are the same; the AOS firmware on both machines are not the same but I doubt this to be the problem; both were recently updated to newer firmware than what we were running previously.  Something tells me the issue is a file missing or different in the CFlash.  The CFlash on the test unit came with a replacement Netvanta 7100; the Netvanta 7100 in our live environment is using the same CFlash we were using prior to the firmware update.  I suspect that the CFlash recently sent to us by the mfg along with the replacement 7100 (we had a unit replaced recently) includes something that our "old" CFlash does not....

Polycom SoundPoint IP Phone Configs - Deprecated Model Error

Due to a series of unfortunate events, I was forced to recently upgrade the firmware on our Netvanta 7100 PBX VOIP phone system at multiple sites.  After the upgrade, when I tried to change phone settings through the management console I received errors after hitting Apply.  Also, under Voice - IP Phone Configs all phone configs are in orange and a message states "Deprecated phone model setting detected.  Please double-click the highlighted item and select a new phone model." 

Any ideas on what I'm dealing with here?  I initially thought I had to upgrade the firmware on all phones to be compatible with the new Netvanta 7100 firmware but after reading the AOS firmware release notes I realized that the current Polycom SoundPoint IP Phone firmware is the right version. The system prompts to select a new model for the Polycom SoundPoint IP 650 phone and lists it as Adtran/Polycom IP 650 from the selection list.  The problem with that is  when I selected a new phone model from the list provided, the phone failed to boot afterward and I had to manually make changes to the configuration files for it to boot back up. 

To add a twist to it all, at another site I did the exact same thing for another phone but different model (Polycom SoundPoint IP 335) and all worked fine.  That is, the phone model was said to be deprecated and was listed as Polycom SoundPoint IP 335.  I had to select a new model from the list and chose Adtran/Polycom IP 335.  

I'm off to try this on another Polycom SoundPoint IP 650 and Polycom SoundPoint IP 335.  To be continued...

Security Errors on Patient Portal

As much as I would love putting blame on the patient portal site administrator to quickly dismiss the issue as I have quite a bit of work ahead of me, a little googleing around made me realize that security errors on patient portal can be due to a number of reasons that are not resolved on the server side.

An SSL certificate error in the Google Chrome browser stating "Your connection is not private" can be due to the site's SSL certificate but can also be caused by the wrong date/time settings on the client.  Additionally, if you are running Windows XPe (Windows XP Embedded) thin clients as I am, not being on Service Pack 3 may be the problem.  There may be other software requirements depending on your OS version and what updates are installed.  I was clued in on this when users reported security errors on patient portal where the https is crossed out in the URL and there is a dreaded red lock with a white X.  When accessing the site on my workstation, there was no error, hinting that the problem was with the client.

Surely the site can still be accessed safely; but to users who have been pounded day in and day out regarding the importance of protecting ePHI and accessing only trusted websites, that can be confusing.  So, recapping, before contacting the patient portal administrator and wrongly accusing him of not maintaining the site, I will, at the very least look to the client machine to do some initial troubleshooting.  Let's not forget it take two to tango, as they say.  That is, what the user sees on the browser is the sum of Client/Server communication.