Installing Tera 2220/2240 in Dell Precision Tower System, and How an Install Went Wrong.

Hey folks, it’s been a little while since I’ve posted and time for some fresh content here.  This comes from a recent customer I worked with that had a very strange performance problem with a system they recently purchased.  The customer had ordered a couple of  Dell Precision T5820 systems with an nVidia GTX1080 and Tera2240 card and they were using some older Wyse P25 endpoints for remote workstation access (a pretty nice setup for doing remote graphics).

The initial problem called in on was that one of the systems would lose its CMOS Time when the system was started up remotely from the P25.  Specifically, when the customer would turn on the workstation from the front power button of the Tower – everything was fine, but when the “power on” was sent remotely from the P25, the system would power on and stop pre-POST with the message “CMOS Time not set, Press F1/F2 to continue” – which everyone knows means the CMOS either got reset or lost it’s time configuration… but in this use case, why??

What is a Teradici Card?

A Teradici Host Access card is a pretty impressive widget for doing HD graphics (CAD, design, modeling) from a remote location.  The HAC can accept input HD Video from an onboard video card, scrape 6 different functions off the motherboard via the PCI bus (keyboard, mouse, audio and several USB device channels), then compress and packetize all of those to send across your network to a hardware or software client with almost lossless video.  This provides the end user access to a high quality user experience while the system stays secure at the office or in a datacenter (meaning: the data stays secured).

One additional cool feature of the Teradici Host Access Card (HAC, from here forward) is that you can remotely power up/down a system that has a Tera card installed.  This is accomplished on the HAC through a 2-wire, power management cable that connects a jumper on the HAC to the Remote Power jumpers on the motherboard of the system where the HAC is installed (picture below).

Tera_PowerMgmt_Cable2

Installation:

The picture above is a Tera2220 with Power Managment Cable attached to the card (white socket/circle).  It’s a standard PCIe device and just plugs into a PCI slot in your system.  If you have a dual socket system and only have one socket populated, check your motherboard documentation on which PCI slots are driven by the installed processor.  If you happen to be in that scenario and plug it into a PCI slot that belongs to the empty 2nd socket, the HAC will power up (it pulls power through the PCI slot) and you will be able to access the WebInterface for the device (AWI), but it won’t be able to interact with the system (mouse/keyboard) because there’s no processor handling the I/O from that PCI slot.  This scenario isn’t an uncommon problem and we’ve diagnosed it quite a few times.

Once installed in the PCI slot, there is also the Power Management Cable (PMC) to deal with.  One end of the PMC should already be attached to the HAC.  At the other end is what equates to a “splitter”.  The power management cable can be used on systems with a Remote Power jumper on the motherboard, or on systems that only have a single  power control jumper for the bezel mounted Power Switch.  The port circled in red above is the connector that will be plugged into the Remote Power socket on the motherboard.  The connector I’m holding (blue circle) is only used if you do not have the 2nd Remote Power jumper on your motherboard.  In that instance, you will unplug the the bezel power cable plugged into the motherboard jumpers and plug the bezel power cable into the socket I’m holding, then plug the red circled connector into the power jumpers on the motherboard.

After that, use the supplied DisplayPort to miniDP cables to jumper the video out from your HD Graphics card into the Teradici HAC.

That’s it for installation.  As long as you know where the Remote Power socket _is_ on the motherboard…

The Fail part…

After a lot of remote troubleshooting of the System, checking BIOS, sending a CMOS battery, Tera HAC configuration and other checks which I won’t bore you with, we got down to asking the customer for a picture of the area around the PCIe slots where the HAC was plugged in to see how “what is plugged in to where”.

Once we got the picture of the motherboard, the picture became much clearer (all pun intended).  Unfortunately, the only obvious jumpers exposed anywhere near the PCIe slots on the T5820 were:  BIOS Password Reset & CMOS reset.  The BIOS Password Reset jumpers are covered/jumpered by default on Dell systems and the CMOS jumpers were the only uncovered jumpers available (in the Red Circle below).

Somehow, some way, the Tera card’s Power Mgmt Cable had been plugged into the CMOS reset jumpers.  So when they executed a remote power command from the P25, the Tera card was closing (read as:  jumpering) the CMOS Reset and wiping the configuration.  This explains how the front Bezel power-on didn’t exhibit the issue when used, but would wipe the config when doing power control from the Wyse P25.

Fortunately, the correct jumper socket for Remote Power was found next to all the Bezel control jumpers at the opposite edge of the motherboard from the PCI slots (noted by blue arrow, below), hidden under all the cables for the Bezel controls (and the socket wasn’t labeled either – that detail was pushed back to Engineering).

T5820_PCISlot_area_1

Once the Power Mgmt Cable was tapped into the Remote Power control socket, the system started working as expected.

Have y’all seen any odd outcomes from what would seem like a routine card installation??  Let me know in the comments…

Extra Resources:
Teradici Installation Instructions

Finding/Setting IP address on Teradici

RDS 2016 & 2019 in a Workgroup or With Active Directory – Licensing Failure

** Update 10/4/2018 –  I just tested out RDS installation on Server 2019 in workgroup mode and the same configuration issues will be experienced and the process below will get you through it.  -Scott **

Ok, so if you are here – you already know this is not a recommended configuration for Remote Desktop Services, but you want to do it anyway.  With my experience in Technical Support with a now very large computer company, your odds of succeeding in this endeavor if things go wrong are about 50/50, but let’s get you some info to assist and get you the best odds of winning.

Remote Desktop Services (RDS) is designed to be in a Microsoft Active Directory integrated environment, meaning there is a writable DNS server in the environment and an AD User/Service database to pull environment information from.  Along with the needed AD pieces, there is also the issue of the RD Connection Broker service won’t install, due to the lack of permissions – which means you do not have an RD Management interface with which you can configure your RD environment.  So given these fail points, without taking other steps you will wind up with an RD environment that cannot be accessed due to RD Licensing configuration failure (yeah, you do need RD licenses, too).

Here’s what you will see in EventViewer:System logs:

And when you go to RD Licensing Diagnoser, you’ll see this:

Licensing mode for RDS Host server is not configured resized 600

And looking in RD Overview in Server Manager, you get:

[clip_image00263.jpg]

Since you don’t have the GUI to work with to configure RD Licensing with, we’re going to have to go about this differently.

** Also, if you installed RDS on a system with Active Directory installed, you may, or may not, get the Overview GUI installed on your server (error pic above).  Even if you do have the GUI installed in this scenario – it’s almost a 100% chance that the Licensing Configuration through the GUI will not work.  The tweeks below work to fix RD Licensing for both Workgroup and AD scenarios.


Open up Regedit and navigate to: HKLM\Software\Policies\Microsoft\WindowsNT\TerminalServices

You’ll need to add two keys:

  • LicenseServers  (string value), with a value of your FQDN of the License Server instance.  One option instead of using a FQDN is just use “localhost” to point the RDS instance to look on the workgroup server for the RD Licensing Instance (as long as RD Licensing is on the same workgroup system).
  • LicensingMode  (32-bit DWord), with one of 2 values:  2 – for Per Device mode  or 4 – for Per User mode

Once you have those set, restart the RD Licensing Service and RD Session Host Service and then re-run the RD License Diagnoser – it should run clean now.

** Other important note here…  An RD Licensing instance can handle Per User and Per Device licenses and hand them out with no problem to multiple RD Session Hosts, but a single RD Session Host can only ask for 1 type of RD License – either Per User or Per Device.  This is a common issue where Per User licenses are purchased and installed, but the Default licensing mode configuration for RDSH is “Per Device”.  So, RD will hit your RD license host and ask for a Per Device licenses, which it doesn’t have.  Changing the licensing mode to “Per User” fixes the issue.

Good lucks out there!  Comments??

Wyse Mangement Suite & Blast Deployment

Hey folks, it’s been a little while since I’ve shared something.  But this afternoon I found something worthy.

A customer has some Wyse 3040’s (ThinOS) already deployed, connecting to Horizon View 7.3 on the back end, and now they want to test performance with the Blast protocol instead of PCoIP.  The customer is using Wyse Management Suite to configure their endpoints and is using only 1 endpoint to test with.

How to do this???

The customer is using ThinOS 8.5_012 on their endpoints, but the process is pretty much the same for most WMS/ThinOS clients that support Horizon View.

First, the endpoint needs an additional package deployed to support Blast Protocol.  In ThinOS, the Horizon View Client only supports RDP & PCoIP protocols and manual configuration will only display those protocols in the drop down menu.

If you are using On Premise WMS (locally hosted):

  1. Navigate to where you unpacked your downloaded ThinOS package.
  2. Drill into the PKG folder and locate:  horizon.i386.pkg
  3. Copy that file to your repository on the server that is hosting WMS (..\WMS\LocalRepo\repository\thinClientApps)
  4. Wait a few minutes for WMS to update it’s inventory.
  5. Go to App & Data on the top toolbar & on the Lefthand side:  App Policies – Thin Client.
  6. Create a policy to deliver the new package to the endpoint & confirm the installation by checking SystemTools:Packages and verify that Horizon.i386.pkg is installed.

If you are using Cloud Based WMS, the packages for your ThinOS should already be listed and available.

Once that is done, then just deploy your configuration policy to the endpoint device groups and test.

Hope this helps.

VDI in the College Campus, a Success Story.

Any good VDI Techie knows that College computer labs and VDI were made for each other.  Before XenDesktop & Horizon View took over the leading roles in “We Do VDI Better” in the last three years, there were plenty of computer labs using Remote Desktop services and VDI-in-a-Box.  And before that, Active Directory attached PC’s with some well documented re-imaging process for those times when “somebody did something and now it doesn’t work”.  As times have changed and needs for protecting data have increased, offering accessible computing resources to College students (BYOD or not) have also increased, and a robust solution computing solution for campus environments has always been just out of reach.  Until recently….

The University of Arkansas was recently awarded this year’s Tech Target’s Access Innovation Award for their implementation of a campus-wide accessible VDI based end-user computing project.  The University of Arkansas partnered with DellEMC and leveraged their VDI Complete Solution – a package of VMware vSAN HCI solution, VMWare Horizon View, nVidia GPUs, DellWyse Thin clients & Industry proven PowerEdge R730 servers.  DellEMC was able to provide a sturdy, high performance solution (in computing and graphics processing) to cover 27,000 students on the Fayetteville, AR campus through Lab accessed resources and “roaming” access through campus WiFi and off-campus access.

—————————————————————————————————————————–

Dell EMC congratulates the  University of Arkansas for winning the Access Innovation Award. If you are interested in learning more about how VDI Complete is making high-quality, speedy VDI deployments possible for institutions and organizations across the country,  visit https://experience-vmware.com/vdicomplete/.

CAD Graphics Solution – Converting DVI to DisplayPort

Hi folks,

I recently worked a case with a customer who was setting up a dedicated remote graphics workstation leveraging a Teradici Host Access card for remote access.  The problem they were experiencing was the DellWyse 7030 was connecting to the Teradici card, but they were getting a message “No Signal”.

Here’s the hardware setup:

I had never seen a Quadro K6000 yet, so just to figure out the “lay of the land” the customer sent us a picture of the back of the server – with the Tera card and Video card and current cabling.  The K6000 is kinda unique, aside from having over 2000 cuda cores for graphics processing and using a single-PCIe and two slots wide.  That’s all pretty cool, but the uniqueness is that it has 4 video out ports on the back and it’s made for single user/client video.

However, there’s a problem with the configuration of the 4 ports that can cause some issues when trying to leverage a Tera2240 card.  The K6000 has 2x DisplayPort outputs and 2x DVI outputs, and that’s a problem when trying to light up 4x miniDisplayPort connections to feed 4 monitors on the 7030 endpoint.

The Tera2240 is designed to work with DisplayPort connections only, so it’s packaged with 4x DisplayPort to miniDisplayPort cables to do the Interconnection between the video source (DisplayPort) to the Tera card (miniDisplayPort).

Initially, the customer had configured the solution as in the picture below.  The DisplayPorts on the K6000 are shaded in the picture, but I highlighted them with the Blue circle (there’s a better pic further down), but note that they are unused.

IMG_1207-2

From the image above, the customer had purchased two consumer grade miniDisplayPort (mDP) to DVI adapters to make the connection between the DVI output on the K6000 and the mDP input on the Tera2240.  It seems like it should work because there’s a DVI port on one side and mDP on the other side, right??

Not understanding the solution, they wired it up as above and didn’t understand why it didn’t work and they were getting a “No Signal” message after connecting to the Tera card from the DellWyse 7030.

Let’s break down the parts in the solution real quick, which will help us understand how to put it together and be able to get proper video to the endpoint:

Quadro K6000:  The Quadro K6000 does have 4 video out ports – 2x DP & 2x DVI.  However, there is “precedence” in the default video ports as seen in the host operating system, as to which port has Monitor1, Monitor2,…, Monitor4 video out.  This can be changed inside the OS, but the default is best described by a picture.  Ports indicated as 1 & 2 are your DisplayPort outputs, 3 & 4 are your DVI outputs.

K6000-ports

Tera2240:  As shown below, the Tera2240 card has 4 mDP inputs and are labeled in order.  So, this is just as simple as matching up Video Out ports (from K6000 above) to the Tera2240 mDP inputs in the image below, right??

Tera2240

Well… no.  There’s still a problem – with the converters.

Converters:  After doing some research on video signaling and conversion from DP->DVI and DVI->DP, these are two very different processes.  DisplayPort is a much newer and robust digital video & data transfer interface (go to market ~2008) and is backwards compatible with VGA, DVI and HDMI displays formats.  This is accomplished with a simple passive (read as:  non-powered) adapter that takes the DP signal stream input and strips out everything but the needed signal (based on the adapter output type) and putting it out on the other side of the adapter.  Unfortunately, up-converting from VGA/DVI/HDMI to DP takes a bit more work from a processing side and requires a power input to assist with the computational processing.

So it is important to know what your video source is and what your output is supposed to be and that you get the right adapter for it.


So, putting all of these pieces together, here is what the configuration should look like to provide a Quad Monitor experience leveraging the K6000, Tera2240 & have the video come out properly on the Dell Wyse 7030 Endpoint.

  • K6000 ports 1 & 2 will use the provided DisplayPort to mDisplayPort cables (noted in blue) to connect into ports 1 & 2 on the Tera card.
  • Ports 3 & 4 will use a short DVI cable out (noted in red), which will need to plug into an Active/powered DVI –> mDP up-converter (noted in tan) to translate the DVI signal into a DP capable signal, plugging into ports 3 & 4 on the Tera card, with likely an assist from USB power off the back of the server to power the Active up-converter.

Setup2

Here’s a look at some examples of Active Up-converters to go from DVI–>mDP :
Here…   and…   Here…   off of Amazon.com  (Disclaimer:  I’m not necessarily recommending either of these, they are just examples.  Verify with the vendor that it will work or they have an equitable return policy)

There’s a lot of good info on the DisplayPort spec: here.

Hope this helps.  Hit me with questions.

“I can’t find my Teradici Card”

In the world of IT and High Definition Workstation Graphics, you’ve probably run across implementations leveraging a high performance graphics card in a workstation to do Design and CAD-type of work.  In many instances, considering what you pay for one of these beefy graphics workstations, you will want to either:

  1. Have a configuration where you can allow a remote/contract designer to work on a project without having to come to your place of business; or
  2. You have a team of designers working on a very critical project that requires high data security – either through restricted physical access, restricted Data “leakage” (meaning someone can’t copy the design files and take them with them) or performing fast & reliable backups on a scheduled basis (data protection).

Teradici Host Access cards are the “go-to” solution for enabling this type of work environment.  Working in Tech Support for a major computer manufacturer, I occasionally see an issue with a newly deployed/re-deployed Teradici card where you cannot access the Administrative Web Interface (AWI) for the card to do the basic configuration of the card.  For whatever reason, it cannot be accessed on the default IP (192.168.1.100) or found by other rudimentary means.  Here is a quick list of common problems and solutions to locating the IP of the Tera card.  These steps were built from a Tera2220 card (dual-port DisplayPort configuration).


When the Teradici card doesn’t show up with the default IP address on first setup or doesn’t pull an IP from DHCP – that can cause some problems with first connection to the Tera card because it cannot be found on the network.  Some possible reasons for this failure are:

  • It has a static IP configuration already existing on the Tera card (not default of 192.168.1.100/24)
  • NIC cable is bad
  • Card has bad configuration on it (aside from a Static IP configured).
  • Card itself, is bad (usually, this is not likely…)

Ways to work around this:

  • Check DHCP for IP address for “pcoip-host-<MAC addr of Tera card>”.  If card is configured for DHCP, this is the PCoIP Device Name and you can find the IP address in DHCP Leases & connect to the AWI (web interface of the card).  The MAC address of the card is on a sticker on the card, usually on the housing of the RJ-45 connector.   Or can just leverage DNS and open a browser to:  https://pcoip-host-<MACaddrofTeraCard>
  • Direct connect an Ethernet cable and laptop (with 192.168.1.x ip) to the Tera card and try to connect to the default IP (if DHCP is configured on the Tera card – it will fail and fall back to the default Static IP of 192.168.1.100
  • Do the same config as above, but use Wireshark to do a packet capture of the network to discover the MAC/IP of the Tera card.
  • Do a Hardware Jumper reset on the Tera card by the following process.  This is for a Tera 2220 card, so your mileage may vary on what model of Tera card you have:
    • On the host card, just above the RJ-45 shield, there is a section not covered by the Heatsink.  There is a row of jumpers – find a set of 3 jumper pins marked as J15.
    • With the power off, put a jumper on  pins 2-3, install the card and power on the PC.  There is a light on the back of the card by the RJ-45 port – “Heartbeat LED” it will post solid, then blink once.  Once it has blinked, the card is reset.
    • Power down the PC and remove the jumper, then restart the PC and you should be able to access it via normal means: DHCP assigned IP  or  by Default IP if DHCP is not set up on the network, and then reconfigure the device.

As always, I hope this helps 🙂   Lemme know if this does work for you or if you come up with other ways to work around this.

– Scott

GPGPU on Server 2008 R2 – added after the fact…

Hello again,

I came across a customer issue recently where the customer was recommended to install a GPGPU to make Windows Movie Maker (a free video editor in Windows Essentials 2012)  function inside Remote Desktop Services on Server 2008R2.  Unfortunately, Movie Maker still wasn’t working after basic installation of the GPGPU – what’s making this fail?

Initially, the customer was trying to setup Movie Maker in an Educational environment so a class can work with editing and polishing raw video footage.  Being in the Education sector, there isn’t a lot of money to go around, so their solution was cost effective server, with Movie Maker being virtualized in RDS and students accessing the RD sessions with thin clients.

However, due to the requirements of Movie Maker – specifically, requiring DirectX 9c compatibility or newer, it could not be run on stock server hardware.  The integrated video card was a Matrox 200er and even with the Dell drivers installed, the card just doesn’t support DirectX (we tested with this tool:  dxdiag.exe).  Here’s the error message that the customer was getting when trying to run Movie Maker:
l_7d54-tmp

When the customer came to Dell ProSupport, he stated that someone had recommended putting in a GPGPU to make it work, but it still wasn’t working.  This was right after school had started for the year and it was becoming an urgent issue.  We actively troubleshot the issue for several hours, just making sure that everything was installed properly, from RDS to Movie Maker to AMD FirePro.  After coming to the end of the troubleshooting path, it was decided to reproduce the issue in our lab and find a workaround/fix for the scenario.

After a bit of scrounging and seeking assistance with scrounging hardware, we came up with an R730 and an AMD FirePro S9150 card.  After doing some beating on it, I finally found the root issue – RemoteFX was needed in the RDS session to be able to offer DirectX capabilities (namely Direct3D Acceleration) to the application.

Following the process to install RemoteFX, which in Server 2008R2 was designed for RD-Virtualization, I got the RemoteFX driver onboard and also had to install the MS Video Capture driver to redirect video into the RemoteFX shim driver for the RD sessions.  Once this was accomplished, console video was also redirected into RemoteFX – an unfortunate side-effect, but you can still administer the server over RDS.

Now, a login through RDS allows Movie Maker to work and we see this in DXDiag:

dxdiagmoviemaker

 

The DDI Version is 11 and we have Direct3D Acceleration capability now, which covers the requirements of Movie Maker (note Movie Maker running in the background).

Success!

How to Install an nVidia GRID Card on Dell Servers

So, in the process of doing my job here at Dell as a VDI Support Guy in ProSupport, I periodically come across a customer issue where the GRID cards are not properly installed in the system, either because of a misconfiguration/oversight when ordering the server or just forgetting a step in the installation process.

After searching the Internet for some sort of doc or video that details the process and not finding anything, I stepped into our lab here in ProSupport and did an installation video.

Two key points:

  1. Make sure you ground yourself, protect your equipment from static discharge!!
  2. Don’t forget the power cable for the GRID.

 

Enjoy, and I hope this helps someone out.  Please let me know if it does… below… in the comments.

 

It’s a Two-Fer! nVidia GRID 2.0 Licensing and Problems with Chrome & Firefox over RemoteFX

Ran across a problem the other day with a customer who was running a “bleeding edge” Microsoft VDI configuration without a cookbook.

They had a nicely spec’d Dell R730 server running Server 2012R2 Datacenter with Hyper-V/RD-Virtualization, 2 nVidia M60 GPGPU cards and Windows 10 Virtual Desktops.  His initial complaint was that when watching YouTube videos on the Virtual Desktops (VD), the video was choppy and stuttery over Internet Explorer, as if the GPGPU cards weren’t working well, but secondarily – Chrome & Firefox were having severe display problems all on their own, rendering those browsers completely useless.

The customer admitted that they didn’t build out the solution from a cookbook or working document, it was just pieced together based on what his Salesperson had sold him.  We sat down and worked through the configuration of the environment.  Everything looked OK:  Hyper-V installed, RD-Virtualization installed, NIC/nVidia drivers up to date, RemoteFX video enabled on the VD’s.

After having a colleague do some issue reproduction work with the M60’s, we found a problem with the re-engineering and design of the nVidia M60 and GRID 2.0 capabilities.  nVidia was very much ahead of the game with their K1 & K2 GPGPU video cards, being the first to market with something like this, working with OpenGL, Cuda & some DirectX, but unfortunately, it would seem that someone in the Marketing department decided that they were leaving money on the table somewhere.

So, with the release of the new GRID 2.0 generation of GPGPU cards, nVidia had separated the hardware and software functions of the GPGPU cards.  In better terms, the card itself with all it’s processing capabilities, can be purchased and dropped into a server/workstation and used for Compute processing, right out of the box.  However, the GRID 2.0 software piece that manages splitting the very large GPGPU card into smaller WDDM video card slices (via vGPU Profiles) will require a per seat license – meaning that you will have to pay extra for every user that will be leveraging a GRID 2.0 GPGPU.  So, your per seat cost for Graphics Enhanced VDI just went up – exactly how much is still yet to be seen, but initial numbers are around $250-300/seat.  Again, this is only for VDI use of the new nVidia cards.

Unfortunately, the customer’s sales rep wasn’t aware of the new GRID 2.0 licensing and the equipment went out the door with the expectation that everything would work like GRID 1.0.

Research into the Chrome and Firefox issue found some additional interesting problems.  What the customer (and us) saw was the presentation of websites with Chrome & Firefox while leveraging Remote FX/GPGPU was: really bad display, images were chopped up and pieces displayed all over the page, frames to infinity (like when you have two opposing mirrors that are pointed at each other) and just an overall unusable experience.  After doing repro of that issue, to make sure it wasn’t the customer’s installation, we were able to reproduce the same issue.  Doing some checking off the FAQ’s from Chrome & Mozilla, we found that there are problems with the latest versions Chrome & Firefox leveraging the RemoteFX video driver.  There are plans to fix this in their base code, but the only workaround is to disable Video Graphics Acceleration in the browsers, which totally defeats the usefulness (read as: expense) of a vGPU.  So, if you are doing some sort of VDI implementation with Remote FX & video acceleration – stick with Internet Explorer or Edge browsers for the time being.

Chrome display issues with Remote FX discussion thread is here.

New Offerings from Dell Announced at Citrix Summit ’16

Several cool announcements from Dell yesterday at Citrix Summit ’16 in the world of VDI Solutions and VDI related products.

  • New release of Dell Wyse ThinOS (WTOS), v.8.2 which now supports IM based products much better by leveraging the Citrix HDX RealTim Optimization Pack inside the WTOS image for Lync 2010, 2013 & Skype for Business 2015.  Think of it as a bit of a “merge” of the traditional “full client features” of WTOS with the Citrix “special touches” from the Wyse Xenith OS.  Should be fun to see in action soon!
  • Updated version of the Dell Appliance for Wyse – Citrix, which allows you to buy Dell 13G server hardware & deploy a scalable XenDesktop environment via the Dell Quick Start Tool (QST).  This continues Dell’s recent push for simpler deployment of complex IT solutions for the common IT Administrator.

More information here.